[ckan-dev] Custom field persistence

Sean Hammond sean.hammond at okfn.org
Thu Jan 24 09:19:37 UTC 2013


On Mon, Jan 21, 2013 at 11:10:09AM -0500, Ian Ward wrote:
> On Mon, Jan 21, 2013 at 10:50 AM, Sean Hammond <sean.hammond at okfn.org> wrote:
> > I'm not sure whether you can do this (use custom functions in the schema
> > to persist additional content) or whether that would be a good idea if
> > you could. The problem is that, as I understand it, at the model level,
> > i.e. in the database, the package table has certain columns. One of
> > these is the "extras" column which is meant for storing custom data. If
> > you want to store custom data, but you don't want to store it in the
> > extras column, then I'm not sure if there's anything you can do, I don't
> > think there's a good way for plugins to add their own columns or tables
> > to the database.
> 
> Doesn't the spatial extension store its data in another table linked
> to the dataset?

Yes, it looks like both ckanext-spatial and ckanext-archiver have some
custom model stuff, which they implement by importing ckan.model
directly.

Generally importing ckan.model is frowned upon as everything is supposed
to go through ckan.plugins.toolkit. (The plugins toolkit and the plugin
interfaces are meant to define a stable base to build plugins on, so the
plugins won't break easily between CKAN releases/)

However, there may not be a 'nice' way to do what you want, without
using ckan.model directly.

So I guess, if you have to add your own model, then do it following the
example of ckanext-archiver and -spatial, and as Toby says stick to
adding tables only not adding columns to tables.




More information about the ckan-dev mailing list