incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandru Popescu <>
Subject Re: JCR mapping package naming
Date Fri, 10 Feb 2006 01:09:12 GMT
I think I need some more clarifications about the meaning/behavior of auto-update.

Considering that an object ObjectA has a property propertyInA described as auto-update=false;
property was modified after fetching it from the repository, now ObjectA is passed to update.
is happening to propertyInA? Is it ignored even if it was modified?
Same question for some collectionInA, where a property of an object in collection was modified.


.w( the_mindstorm )p.

#: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/8/2006 11:57
PM) :#
> On 2/8/06, Alexandru Popescu <> wrote:
>> promoting it would be: "why is it portals?"
> Because the targeted community is mainly the ASF portal :-)
> We can try to write an article on the OCM concept and use graffito as
> an example. than, we can promote OCM on the Jackrabbit list and other
> areas.
>> I am reviewing right now the collection converters and fixing the exception handling.
After this
>> step, and some small refactorings in the filters, I will be ready for interfaces/inheritance.
>> those are done, or at least addressed we should start promoting it.
> I'm interesting to add new attributes in collection-descriptor (cd)
> and bean-descriptor (bd) (inspired from OJB) :
> 1/ lazy loading  : load the bean attribute or the collection attribute
> when the getter method is called - not when the main object is
> retrieved.
> 2/auto retrieve . this is an alternative to the the lazy loading. If
> false, the bean attribute (or the collection attribute) is not
> retrieved. The developer can use a new method defined on the PM to
> load the object. I prefer the lazy loading solution but sometime it
> can be usefull to control when loading the attribute.
> 3/ auto-update: if true : when the main object is updated, the
> bean/collection  attribute is updated.If false, the attribute is not
> updated. There a lot of case when the graph is loaded (eg. one folder
> & its content)  and only updates are done on the main object.
> Those attributes should gives the possiblity to support deep JCR
> structures without loosing good performances.
> What do you think ?
> I'm also thinking about the inheritance/interface support :
> 1/ Inheritance : the class-descriptor can contain a new element like this :
> <class-descriptor class="CmsObjectImpl" jcrName="graffio:cmsobject">
>  .....
> </class-desciptor>
> <class-descriptor class="FolderImpl" jcrName=""graffito:folder >
>     <extent-class class-ref = "CmsObjectImpl">
> </class-desciptor>
> <class-descriptor class="ContentImpl" jcrName="graffito:content" >
>     <extent-class class-ref = "CmsObjectImpl">
> </class-desciptor>
> A query can be done like this :
> Filter filter = queryManager.createFilter(CmsObjectImpl.class);
> filter.setScope("/test/node1//");
> Query query = queryManager.createQuery(filter);    	
> Collection result = persistenceManager.getObjects(query);
> => if the JCR query is build with the ancestor node type, it should
> work with no many changes in the current code.This solution doesn't
> work if the nt:unstructured type is used.
> This is just an idea and it needs to be review in more details - what
> do you think ?
> 2/ Interface  : I don't understand why mixin node types should be use.
> Java interface have not some attributes. So, I don't see how it can be
> set into the JCR node type hierarchy.
> I think we can also reuse the extent-class element but more
> modification in the current code is required. Still thinking about
> that.
> --
> Best regards,
> Christophe

View raw message