Christian Scholz wrote:
>>> I would imagine performance would be fairly similar as they both use
>>> sqlalchemy underneath. Though as tin uses zope schemas, formlib seem a
>>> little quicker to generate than AT based ones.
>
> I was more thinking compared to Plone ;-)
On my laptop with a small amount of data, collective.tin seems snappier.
I'm not sure how much of this is due to the simpler rendering on the
browser (I'm not using kupu or kss for zope 3 schemas yet), but using
zope3 forms means none or the portal_factory dance, none of the widget
rendering in restricted python and only recataloguing objects once.
One problem with sqlalchemy at the moment is that I need to flush the
session cache at the end of each transaction, as it has no way of
tracking invalidations. It looks like the beginnings of support for
keeping mapped objects in the session cache and only reconstructing them
if the mapped db attributes change is in the works though.
>
> BTW, I still have this idea about what ZPatterns did back then (in sort
> of a hackish way though thanks to old Zope2) which is
>
> - having some factory which creates instances on the fly (might be ZODB
> based then or completely virtual)
collective.tin's TableFolders sort of work like this, using sqlalchemy's
orm to construct an object on container access.
> - having some means of retrieving attributes for them (from SQL or from
> other means like ZODB). This only should get triggered if one attribute
> in the set is also accessed. Thus you could have basic attributes which
> are fast to retrieve and another set which might be more expensive but
> not that often needed.
sqlalchemy has some support for constructing objects from multiple
tables, but I haven't looked into this yet. It could be useful to store
file / body text data in a separate table to metadata for instance.
> - having some means of storing these attributes back via a trigger (and
> only if those have been actually changed). SkinScript which was used
> back then also had the possibility to look at the old value and
> eventually do something with it.
This is similar to how sqlalchemy works, it stores a copy of the mapped
attributes at load time which it compares the current state of the
object to at flush time.
> I liked this very much as it made the actual object more a container to
> which you could configure what attributes are additionally fetched and
> stored. This also was easy to configure so everybody could choose where
> to store things, e.g. storing one field on the filesystem such as images
> etc.
>
> Still not sure how to best implement it these days but it's something I
> want to experiment with.
Personally I don't like the idea of the canonical data store for an
object being split over multiple systems, it makes disaster recovery
planning a nightmare. The ZODB is great, and when that is best for your
data-model, use-it. Especially now BLOB support is nearly there.
You should be able to model such a requirement though, each subset of
attributes has an interface, to which you can adapt an object. Maybe
this object only contains a UID, which each store can use as it's reference.
At some point I would like to experiment with such a system using
collective.tin:
* At the root of the content hierarchy would be a table of (uid,
parent-uid, portal_type).
* For each set of attributes you would create a table and an
interface. e.g one for file data (uid, file-name, file-size, file-data);
one for metadata (uid, title, description...); etc.
* A portal_type would be a list of tables from which to construct the
object.
It should be possible to configure and customize such a system entirely
through the web.
Laurence
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers
