Re: CPSShema and managment of relations between objects

Santi Camps wrote:
>> >> I was been working on this issue.   Here you have more info about a
>> >> solution:
>> >>
>> http://www.kmkey.org/sections/blogs/santi-camps-blog/2006_07_25_manage-relations-within
>>
>> >>
>> >>
>> >> Be careful, I'm also new to CPS, so probably there are a lot of things
>> >> I don't know.   Also  the code is experimental (just committed
>> >> yesterday) so, not ready to be used in production environments.
>> >>
>> >> Hope this helps
>> >
>> > You don't use CPSRelation at all for this, right ?
>>
>> As well, are you using events ?
>>
> 
> 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.

oh ok cool ! Are you planning to define this StorageAdapter per schema
? Ae well, will you allow a flexible configuration from the FTI for this
mapping schema / StorageAdapter ?

> 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.

Yes sure...

Are you interested about contributing your StorageAdapter ?

	J.

-- 
Julien Anguenot | Nuxeo R&D (Paris, France)
Open Source ECM - www.nuxeo.com
CPS Platform - http://www.cps-project.org
Mobile: +33 (0) 6 72 57 57 66

_______________________________________________
cps-devel mailing list
http://lists.nuxeo.com/mailman/listinfo/cps-devel

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFE15VuGhoG8MxZ/pIRAmswAJ0Q4JsrANTv3mkWppdraX5JfjPj3ACfQvTu
gDERfIJ9kvo7TR2352jDLgc=
=LVRf
-----END PGP SIGNATURE-----