Monday 28 January 2008 15:01:01 Christophe Lombart написав: [skip] > > 2. OCM must check class and class versions while loading of saving nodes. > > What > > to do if something goes wrong? I decided to take "best effort" strategy. > > We > > map what we can and leave data untouched if in doubt. and yes, we > > strictly warn developer and admin. > > Can you give more details ?
There's 2 cases. 1st, we read node already created by some other software and our class is not 100% compatible with node structure, different version for example. Our class misses few fields or has few additional. What to do? I do not want just throw exception and panic. Engine must try to map what it can and send warnings to logs. 2nd, our piece of soft just slightly changed and tries write operation on existing node. Should we add new properties new class have? I guess yes. Should we delete properties that left? I guess no without explicit command. Again, no fatal exceptions, just logs. That happens very often not because developers always break things. There 2 reasons for it: 1. No strict type checking for JCR nodes. 2. Recursion. We can add subnodes or links and we usually do. > > 3. OCM must have possibility to find typed objects by parameters and by > > types. > > I don't understand please can you give more details ? > Well, imagine you have NewsPosting class with date, subject and text properties. Node's type is NewsPosting. What I want is auto-generated finders like findByDate(), findBySubject for fields I mark as search keys. Those finders must search strictly NewsPosting nodes, not Votings or ForumPostings. Looking at changes with JSR 283 about query languages, finders might be very helpful for those who does not want to learn a couple of additional query languages. [skip] > > > A couple of words about recursion. There are 2 different apects. First, > > you > > may have class that contains link to itself. It is very convinient for > > things > > like categories and so on. But this is infinite recursion and I use > > "deep" property to make it finite. > > What is a deep property. We have the same problem but is it managed > differently (with a small cahe) Just simple example of content. Some classificator site has article categories. It is obviously tree. Our Category class is recursive itself because contains "List<Category> subcategories" field. But how deep must be this hierarchy? I just say that max is 10 and my OCM knows that it does not go into recursion deeper then 10 calls. > > > Second, when class has properties as class > > instance that has properties as class instance etc... We must go down to > > simple types and make nodes for all of it. May be good solution id > > annotation > > inheritance for this case. If some property marked as persistent so all > > stuff > > that containde in property myst be marked as persistent. > > I'm not sure if I understand correctly but in OCM we are managing this with > BeanDescriptors & CollectionDescriptors. What I'm trying to implement is something like that. I write: @JCRProperty MyBean beanField and all properties of MyBean class with getters/setters inherit this markup if not said @JCRnomap. Well, It needs to be tested. Right today I found more problems with this then advantages. But generally speaking OCM must be recursive by all means. About path, IDs and ORM influence. After reading of previous discussion I believe we have to think completely different way with tree data structures like JCR. Full path is not absolutely correct instance identificator because we map trees, not tables. For instance, node L1 has subnode L2 for first run. Then we add subnode L3 to L2. Is path to node L1 changed on second run? No. Is mapping changed? I think, yes. What is interesting in this situation, that JCR does not have restriction for us just to add subnode antime. There's one beatiful thing with JCR: recursion which makes big difference between JCR and relational databases. I think about dynamical generation of mapping. It's easy with languages like Perl where everything typed dynamicaly. Byt anyway, we can make everything just java,lang.String :) OK, this is subject of separate academical discussion :) (this is joke, hope you guys understand) -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
