@Tim: apologies for huge delay in responding on this. Missed this when first came through and only noticed this now when reading back threads ...
On 24 May 2010 10:05, Tim Black <[email protected]> wrote: > On 05/23/2010 03:51 AM, Rufus Pollock wrote: >> On 22 May 2010 21:25, Tim Black <[email protected]> wrote: [...] >> If so that at least one other example of a >> standard plugin use-case and I we ourselves have implement this kind >> of feed caching in http://www.openshakespeare.org/ as a way of pulling >> content from a wordpress CMS into the main site (that's how word of >> the day is generated for example: >> <http://www.openshakespeare.org/word/read/bilbo>) >> > Are you using VDM for the feed caching? I note this demo: > http://knowledgeforge.net/okfn/vdm/file/cb5116104817/vdm/sqlalchemy/demo_simple.py. Not particularly, we use VDM for 'revisioning' all our objects so we can have version-control/wiki-like features (diffs, rollbacks, changelogs etc) > CKAN (http://knowledgeforge.net/ckan/trac/) has features similar to what > I'm trying to implement (versioning, tagging, groups, recent changes). > I note http://wiki.okfn.org/ckan/doc/schema/--is it possible to make the > following 4 kinds of packages (each with its own distinct database > schema): congregations, people, offices, and roles, then make a > one-to-many relationship where one congregation has many people, and > each person has one or more officers or roles? I need to store data for Yes, you could easily support that schema and versioning and recent-changes are supported out of the box by VDM (in essence vdm is a plugin to sqlalchemy that allows you to revision/version objects and relations. [...] > I'm also finding the ideas in the CKAN documentation useful as I'm > figuring out how to manage our federated church directory data. Where > is the code or the docs on how you "exchange...metadata changesets > between different CKAN instances"? That's going to be a key feature of There's no documentation in the core docs yet but the code itself as a decent docstring and is reasonably readable: <http://knowledgeforge.net/ckan/hg/file/7f472e98f5a6/ckan/model/changeset.py> > the Reformed Churches Locator (RCL) software--one RCL instance will > regularly read in feeds of other RCL instances' data. I'm planning to > use UUIDs to avoid duplicate data, but am finding it tricky to prevent > duplicate data from non-RCL feeds that don't provide a UUID. See > https://blueprints.launchpad.net/reformedchurcheslocator/+spec/versioning for > my initial methods of avoiding duplicates. I think your > duplicate-avoiding code must be in here: > http://knowledgeforge.net/ckan/hg/file/f6c0d4e0950a/ckan/getdata/ ; is > that correct? No it's in that changeset file. [...] Rufus -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
