[Grok-dev] Re: 0.14 wishlist items
Martijn Faassen
faassen at startifact.com
Fri Jun 13 12:44:41 EDT 2008
Hi there,
Wichert Akkerman wrote:
[snip]
> Keep in mind that 'data export' as I think you intend it is something
> very different than 'zodb export' other people refer to:
>
> * ZODB dumps (like the .zexp dumps Zope2 produces) are a full
> representation of all data in the system. This means it is highly
> tied to the specific versions of packages you have installed and
> lots of implementation details. Such a dump is useless for most
> purposes except backup and restore or moving data between two
> systems that are completely equivalent.
>
> * data dumps that contain more 'normal data'. With that I mean things
> like objects and their data as defined in a schema. This is data
> that has a well defined structure and can easily be handled by
> standard tools.
Yes, these are two very different use cases. Thanks for pointing this
out; I was assuming one from the initial request but it turns out to be
the other one. :)
The second case is very hard/impossible to do in a completely general
way. A generic piece of code has only a faint idea what kind of complex
classes you're using for your application after all, and it doesn't have
any idea about what would be a nice representation in, say, XML, of this
same information.
What we could create is the following:
* an infrastructure for exporting and importing content. We could
consider z3c.vcsync for this. It does much more, but it does contain
infrastructure for exporting and importing content. Whether it's good
enough for the generic Grok case, I don't know.
* For schema-driven content, there's z3c.schema2xml which can be used to
generate an XML representation of content. For anything else, we could
provide some form of plugin structure so you can define whatever you want.
I don't see it as very realistic to provide an infrastructure that's
guaranteed to export *everything*, though, without some manual, and
possibly complicated, work for the application developer.
Regards,
Martijn
More information about the Grok-dev
mailing list