On 10/4/05, Costin Leau <[EMAIL PROTECTED]> wrote: >As I've said, considering that the developer has to open a session in >order to create the persistence manager it has a reference so he/she can >manually logoff. Session management is not the persistence manager >concern.
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 ? >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 ? >Try to do an insert and remove - a simple UC. >The current interface doesn't allow this and we are talking >about basic operations not collection findings, proxies or caching. >It's ... wierd to see discussion about 2nd level cache when basic >INSERT/UPDATE/DELETE methods do not exist even as signatures. Yep, some refactoring is needed there. Again, the code was used to build a prootype and now it is time to review all think. Christophe
