incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandru Popescu <the.mindstorm.mailingl...@gmail.com>
Subject Re: JCR mapping package naming
Date Thu, 09 Feb 2006 12:53:26 GMT
#: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/9/2006 10:59
AM) :#
> First, this is only a brain storming and of course we have to define a
> planning.
> 
> All I can say is :
> 1/ I would like to have inheritance/interface support in order to work
> on the Graffito modules. I have also some deadlines.

Same priority here.

> 2/ Is it possible to use this framework in production without
> affecting the performance ? I'm not sure. That's the reason why
> auto-update, auto-retrieve and the lazing loading can help. I'm ok
> this is not simple but we have to provide this kind of mechanism to
> optimize the object graph load. OJB supports lazing loading without
> byte manipulation. I'm going to review their solutions. It is based on
> a java proxy.

Agree. With the single notice that once we have inheritance than some mapping tricks can be
performed so that the performance is not way too bad.

Auto-update: agreed, this should be supported soon.

Auto-retrieve: still not clear what this is. Any links?

Lazy loading: once you name java proxies you are talking in terms of interfaces. Java proxies
are
working only against interfaces.


> 3/ If it can help you, why not to create a version and a branch. By
> this way, the upcoming changes will not disturb your dev team.
> 
>

This would be an option. But usually the experiments are taking place on a branch and the
stable
code stays on the trunk :-).

> Now, the planning : what do you want ? I'm ok to work on the
> inheritance/interface.
> The most important think is to defined a nice setting in the mapping
> file. I mean how can we  define inheritance in the class-descriptor.
> As usual, we can start the first implementation and if needed,
> refactor the code after.
> 

As you can notice from the above, we have quite the same priorities:

1/ interface/inheritance
2/ optimizations: auto-update, auto-retrieve (???), lazy loading

Maybe you already got some ideas about interface/inheritance, so why not start a new thread
on the
ML about this? Than we can reach the conclusion and see where each one can help.

cheers,

./alex
--
.w( the_mindstorm )p.


> On 2/9/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
>> #: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/9/2006
1:35 AM) :#
>> > On 2/9/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
>> >> Hi Chris!
>> >>
>> >> Those suggestions look really interesting.
>> >> But, I would really like to have a stable enough version with correct exception
handling and clean
>> >> code. Moreover, before starting to support advanced features, we must cover
the normal usage
>> >> scenarios first. Afterwards, the way is free to add support for those.
>> >>
>> >
>> > Next month, one guys in my company will start the first Graffito
>> > modules (GraffitoNews & GraffitoForum).
>> > We needs inheritances, interfaces for that. I would like to start the
>> > implemenetation asap.
>> > How long is necessary for your code clean  up ? what is it exaclty ?
>> > Is it mainly the exception handling ?
>> >
>>
>> Next week we are gonna start heavy usage of graffito-jcr. Considering this I need
it as reliable as
>> possible :-). And by this I mean:
>> - me to be able to guide the team
>> - the tool to provide sufficient good feedback so that we will not stuck. This includes
enough API
>> to handle normal scenarios, good error reporting, clean exception handling, etc.
>>
>> As you said the project started as an experiment. Considering that we are gonna use
it in production
>> it needs to reach a good-enough level at least. I agree that good-stuff (like the
things you were
>> talking about) will be needed, but till that moment I need the above mentioned things
first. Without
>> them the team will not be able to use it or will not be able to be proficient (which
is definitely
>> not good).
>>
>> I think I have finished the first round of refactoring. Now, if I find enough time
I can focus on
>> inheritance. As I said in the previous mail if we are able to support inheritance
in mappings than
>> this will offer a quick solution (even if not so ellegant) for a fake lazy loading,
auto-updates.
>>
>> I am not sure what auto-retrieve is. I have re-read your fragment but it is still
not clear. Can you
>> further explain?
>>
>> You should be aware of the fact that lazy-loading is a very complex task, and it
cannot be solved
>> with proxies (usually the only possibility to handle it reliable is with bytecode
manipulation).
>> Moreover, lazy-loading is opening the doors of further problems like session handling
(see
>> OpenSessionInView approach from Spring, or HibernateInterceptor from Hibernate).
Before jumping to
>> it, we have enough other things to deal with.
>>
>> Once we are able to provide some inheritance support, we can immediately start working
on these
>> ideas. Meanwhile, we can continue to discuss about them so that we have 'em clarified.
>>
>> I am definitely not trying to freeze the status or the set of supported features.
I am only trying
>> to say that we should consider them in order, so that we can start offering good
solutions for each
>> stage.
>>
>> best regards,
>>
>> ./alex
>> --
>> .w( the_mindstorm )p.
>>
>>
>> >
>> >> Indeed i find interesting the lazy loading and auto-updates. Still I believe
that some of these
>> >> features can be supported immediately we have inheritance for example (by
using light classes).
>> >
>> > sorry I don't understand - How can we support inheritance ?
>> >
>> >> This
>> >> is the main raison I am trying to keep focus on having the full functionality
in place. Some of
>> >> these features are quite complex to be implemented (take for example lazy
loading).
>> >>
>> > auto-retrieve, auto-update are not complex. We have to add some
>> > conditions in the PM.
>> > I think a java proxy can help for the lazy loading but yes it is more
>> > complex. we need to keep a reference to the PM in the java proxy.
>> > Inheritance, interface : that' so cool but not so easy :-) but why not
>> > too make some experiences, prototyping, ...
>> >
>> >> Please don't take me wrong :-), but I would really need an usable version,
before being able to
>> >> start thinking at those.
>> >
>> > Please, let's review together how we can split the work. Currently it
>> > is not a full time job but I can find a lot of time during the
>> > upcoming weeks. My plan is to start the inheritance/interface coding
>> > in the middle of the next week. Now, we can at least share ideas and
>> > speak about the design.
>> >
>> >
>> >
>> >
>> >
>> >
>> >>
>> >> cheers,
>> >>
>> >> ./alex
>> >> --
>> >> .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 <the.mindstorm.mailinglist@gmail.com>
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. Once
>> >> >> 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
>> >> >
>> >>
>> >>
>> >
>> >
>> > --
>> > Best regards,
>> >
>> > Christophe
>> >
>>
>>
> 
> 
> --
> Best regards,
> 
> Christophe
> 



Mime
View raw message