incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christophe Lombart <christophe.lomb...@gmail.com>
Subject Re: JCR mapping package naming
Date Thu, 09 Feb 2006 08:59:32 GMT
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.
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.
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.


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.

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