Nuxeo mailing list archives
[CPS-devel] CPSShema and managment of relations between objects
Anahide Tchertchian
at at nuxeo.com
Tue Aug 8 11:59:32 CEST 2006
Hi,
Sorry for answering so late... Well, CPSSchemas is not the way to go in
my point of view, CPSRelation is way more adapted to this kind of
feature, but if it's working for you this way, good :)
Anyway, I'm just going to give some information about CPSRelation features.
>>No, I'm not using CPSRelation at all, just store de docid of the
>>related object, and then always search for its last revision. Use of
>>CPSRelation could be added, but my plans are to develop a
>>PostgresStorageAdapter to be used instead of current
>>AttributeStorageAdapter, and use the powerful of SQL to work against
>>huge amounts of data, in special for long running reports. For 1-N
>>relationships I don't need more, and for M-N relationships I'm
>>planning to add a MN Relation Widget storing data in an relation
>>schema, so at the end, it will result in a set of tables (one per
>>schema) structured as a well designed relational database. In any
>>case, I want the SQL StorageAdapter to be optional, so the software
>>can work just with ZODB, and activate the SQL StorageAdapter just when
>>needed.
Note that there are several types of graphs used in CPSRelation, storage
can be done in IOBTree structure or in any kind of backend provided by
the Redland framework (bdb, mysql, postrgesql for instance).
I think it would not be so difficult to add an sql graph if you'd like
to do it your own way.
>>On the other hand, I use events, yes, but only when deleting an object
>>with relation fields. When adding, I tried to use Z3 events, but was
>>not possible due to the Z3 adding events are called before the data is
>>committed by CPSSchema, so I have to add the feature in a
>>postCommitHook. This is ugly, because forces everybody that want to
>>use relations fields to use or inherit from my class. If a Z3 event
>>was raise when CPSSchema finish its work, relation fields could be
>>used on any object.
>
>
> ok gotcha.
>
>
>>Finally, another ugly issue is that I'm storing a false proxy in
>>proxy_tool._rpath_to_infos for related objects, so they aren't deleted
>>by the purge repository while there is any relation pointing to them.
>>This could be done better storing the relation in the
>>portal_relations and changing the portal_repository purge feature to
>>check also relations to detect live and dead objects, considering live
>>an object being pointed by a relation. But I don't walk that way
>>because it needs to patch the repository tool, and I don't want to do
>>it if you are not interested on that patch.
The CPSComment product uses CPSRelation to store relations between
documents: a document is commented, its comment is actually stored in
portal_comments (and not in the hierarchy of workspaces and sections),
and the two documents are linked via CPSRelation.
The document docid is used as an identifier.
Some additional relations can be added between comments (to state that a
comment is a reply to another one for instance).
When comments or commented documents are deleted, Z3 events allow to
delete now useless relations.
The default graph is an IOBTree graph to allow users to use the product
without having to install the Redland framework.
A commit hook has also recently been added to be able to add/remove
relations at the end of the transaction (this is not used for CPSComment
as relations are used to control security set on the comment, so the
relation set is needed before the end of the transaction).
If you want to have a look at it, I would advise to checkout the
abstraction branches of the products: CPSRelation has refactored to be
able to switch from a type of graph to another one without having to
change third party code. See:
https://svn.nuxeo.org/pub/CPS3/products/CPSRelation/branches/abstraction
https://svn.nuxeo.org/pub/CPS3/products/CPSComment/branches/abstraction
Note that to comment a document, you have to allow discussion on it
(edit this on the metadata page).
Feel free to ask for any other information.
Regards,
--
Anahide Tchertchian, Nuxeo
Mail: at at nuxeo.com - Tel: +33 (0)1 40 33 71 60
http://www.nuxeo.com - http://www.cps-project.org
More information about the cps-devel
mailing list
This list archive provided by Nuxeo, the
leaders of open source ECM.
Check out the Nuxeo 5 open source,
standards-based ECM project.