[ckan-discuss] Architecture Best Practice

Sat Apr 27 11:00:46 BST 2013

Thanks so much for your feedback!

I am already using a customization of your IDatasetForm extension (
https://github.com/MarinaMartin/USMetadata ) for our initial demo
deployment. But wouldn't 300 custom fields x X agencies still equal a
tremendous number of fields in a single table, just conditionally displayed?

Does the current CKAN 2.1a fully support organizations right now?

Thanks
Marina

On Sat, Apr 27, 2013 at 2:00 AM, Sean Hammond <sean.hammond at okfn.org> wrote:

> > I am considering two scenarios for a multi-department deployment and
> would
> > like to hear from others on the pros/cons of each.
> >
> > In the first scenario, each department has its own instance of CKAN.
> >
> > In the second scenario, I run one central CKAN, with multiple
> organizations
> > turned on and each department using a different organization.
>
> Either way is possible, which one fits best depends on your exact needs.
> A single CKAN using the organizations feature will be much simpler and
> easier to setup.
>
> > Many of my departments have significant customization needs in terms of
> > fields/facets -- generally around 300 custom fields each. These custom
> > fields do not overlap, so if I'm using one central CKAN, this would add
> > thousands of fields to the schema. I imagine this would cause performance
> > issues.
>
> Wow! That's a lot of custom fields. I'm not sure whether this would
> cause performance issues or not (I don't know of an example where
> someone has had so many custom fields).
>
> I don't think you would have to add all of the custom fields from every
> organization into one massive schema. You can have a different schema
> for each organization. You can use the IDatasetForm plugin interface,
> which allows you to return different schemas for different datasets,
> based on each dataset's package_type field. And you would use a
> different package_type for each organization.
>
> > I am also concerned that letting multiple organizations share one CKAN
> > means that adding extensions or customizations that just *one*
> organization
> > needs becomes a really tall order, and one organization deploying a
> > potentially broken extension puts all other users at risk.
>
> Potentially, I suppose. On the other hand, if you have a separate CKAN
> instance for each one of your organizations, and they all deploy lots of
> different extensions, this could cause you problems as well. Many CKAN
> instances, many custom extensions, many things that can break.
>
> Extensions may also cause problems with "federation" of multiple CKAN
> instances, e.g. with the harvesting process. Depends on the extension, I
> suppose.
>
> It seems to me that either way you do it, if you're planning on managing
> all these organizations, you probably want to keep the number of
> different extensions used within control.
>
> _______________________________________________
> ckan-discuss mailing list
> ckan-discuss at lists.okfn.org
> http://lists.okfn.org/mailman/listinfo/ckan-discuss
> Unsubscribe: http://lists.okfn.org/mailman/options/ckan-discuss
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-discuss/attachments/20130427/0e00a66b/attachment.htm>