[ckan-discuss] Architecture Best Practice

Sat Apr 27 13:12:50 BST 2013

On Apr 27, 2013 6:09 AM, "Marina S. Martin" <marina at marinamartin.com> wrote:
>
> 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?

If you're using convert_from_extras and convert_to_extras you'll have 300
rows in the extras table *per dataset*. You'll probably want to make tables
dedicated to each org in your db for storing the extras, or possibly store
them all together as a single json-encoded field.

Storing them json-encoded kind of limits the sort of queries you can
perform, but might not be a problem if you're using solr for most things.

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

Yes, Organizations were introduced in 2.0.

>
> 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
>
>
>
> _______________________________________________
> 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/02abec0c/attachment.htm>