[ckan-dev] Import cpomplex, nested metadata schema with attributes ...

[Ryan Clark]

Unfortunately it isn't public (or remotely complete) yet. It will be, but I have some silly restrictions imposed on me and can't share it just yet.

However, the spatial extension was the example that I followed to do this.

https://github.com/okfn/ckanext-spatial/blob/master/ckanext/spatial/commands/spatial.py line 52 defines "initdb" function that is executed via paster. This creates database tables by calling a function at:

https://github.com/okfn/ckanext-spatial/blob/master/ckanext/spatial/model/package_extent.py line 21 "setup" function.

That setup function really just checks if tables already exist and then generates them if they don't. But the basic SQLAlchemy stuff that actually does the work is below.

1. Define a class for your information -- in this case class PackageExtent(DomainObject). Inheritance from DomainObject helps tie it into CKAN and gives you some helper functions.
2. Build the SQLAlchemy Table() for your database table. This is on line 70 in the define_spatial_tables function.
3. Build the SQLAlchemy mapping between your class and your table. Line 75 in the same function.

The last important step is that the define_spatial_tables function needs to be called whenever CKAN runs. They do this by making a plugin that implements IConfigurable. The plugin's configure function will run every time that CKAN is started, and they basically use that to get at the define_spatial_tables function.

I hope that helps! Sorry that's the best I can do!
____________________

Ryan Clark
ryan.clark at azgs.az.gov
(520) 302-4871






On Feb 18, 2013, at 10:12 AM, Ian Ward <ian at excess.org> wrote:

> On Mon, Feb 18, 2013 at 11:40 AM, Ryan Clark <ryan.clark at azgs.az.gov> wrote:
>> I'm working in a similar situation -- complex XML schema for metadata
>> (ISO19139) that needs to be stored in CKAN "packages". I'm coming at it the
>> other way, though, to start. That is, I'm working to export ISO19139 from
>> CKAN Packages.
>> 
>> I found that the "extras" concept wasn't exactly the right idea for the kind
>> of relational data that I wanted to append to the CKAN package. Instead, I
>> built a CKAN plugin that builds additional tables in the database (through a
>> paster command), and correlates those tables to CKAN's package and resource
>> tables through foreign key relationships. Then I can grab the bundle of
>> related database objects and pick them apart to export an XML doc.
>> 
>> In the near future, I'll be tackling it in the opposite direction: get the
>> XML, convert it to CKAN package plus additional related tables.
>> 
>> I looked at the ckanext-spatial extension for inspiration about how to
>> develop the additional tables and the paster command. If this sounds like a
>> good solution to you, I would take a look there.
>> ____________________
>> 
>> Ryan Clark
>> ryan.clark at azgs.az.gov
>> (520) 302-4871
> 
> Hi Ryan,
> 
> I was considering that route if my current approach using lots of
> extra fields was too slow.
> Is your plugin public by any chance?
> 
> Ian
> 
> _______________________________________________
> ckan-dev mailing list
> ckan-dev at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-dev
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20130218/0d59a124/attachment-0001.html>