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: Re[2]: [jcr-mapping] PersistenceManager
Date Tue, 04 Oct 2005 11:45:59 GMT
On 10/4/05, Costin Leau <costin.leau@gmail.com> wrote:
>
> Hello Christophe,
> > Ok ! Now I understand you :-). The current code was build to make a
> > prototype and discovering the JCR spec and now it is time to review all
> > thinks.
> > We have 2 possibitities :
> > * Use distinct components : PersistenceManager and a JCR session object.
> In
> > this case, we can forget all methods like exist, logout, ... in the
> > PersistenceManager
> > * Use only the PersistenceManager which encapsulate the JCR session. but
> in
> > this case, we have to build a component manager/factory or other thinks
> > which can initialise the PersistenceManager correctly.
>
> > Is is a good summary of our discussion ? What do you like solution 1 or
> 2 ?
> There are other possibilities:
> 1. The Persistence Manager is configured per Repository and can
> retrieve the session by itself.
> 2. It's a variation of the first solution. The Manager contains only
> persistence related methods but is still session-bound (it requires a
> session). PersistenceManager dependencies however are initialized by
> the manager itself - for example right now the developer has to take
> care of converters and query manager even though this is not his
> concern but actually the PersistenceManager; the internals have been
> externalized.



What do you think if the persistence manager dependencies are initialised
/injected by the Spring assembly script ?

>>You mentioned something about OJB or Hibernate in the proposal. Take a
> >>look at the Session interface (org.hibernate.Session) and trim it
> >>down.
> >>A simple interface would be:
> >>add(Object)
> >>remove(Object);
> >>update(Object);
> >>exists(Object);
> >>Note I did not mention any path as this can be already present in the
> >>XML mapping. If these basics are supported the path can be easily
> >>added later.
>
> > So, you force to have in each object, the attribute "path" - Correct ?
> It's just an idea to make a prototype at the beginning and then
> generalize, not the other way around. And yes, the mapping has to
> contain the path (the naming or if it's an attribute/property is not
> important).


Ok let do the prototype and we will see.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message