Hi! Sunday 16 March 2008 22:32:55 Christophe Lombart написав: > > So question is: why not to use UUID as primary key for OCM? In my > > opinion it is only one reliable key in JCR. OCM code may just force all > > OCM nodes to have jcr:uuid property and relay on it. > > For me, this is not a good idea because UUID is not mandatory in JCR. OCM is not mandatory by JCR too but this fact does not stop you from development. :) UUID is mentioned many many times in JSR-170 so it is madatory in JCR but optional for some nodes you do not care of. Referencial integrity is not possible without UUID. Implementation of JCR is not possible without UUID. > Furthermore, you are forcing to apply the mixin type > "mix:referenceable" to each node. Is it big deal? In your former implementation you forced ocm:discriminator mixin type for nodes with ugly type registration code. Node with mix:referenceable is quite better because it forces referncial integrity of node and developer can be sure that references to OCM nodes will be OK. What's bad wiht it? Imagine I move some node from user's home to public area. All references made to this node before move will be OK after move.
> I'm not sure this is a good idea for all use cases. I can tell you 5 uses cases where path is very questionable idea causing incosistences. Tell me one use case where UUID is bad. :) And by the way, UUID operations are 25-50% faster then path operations. Furthermore, UUID can be used as unique instance ID independent of node location. Fetching by UUID you can always return correct path for oubject. You can place object where you want. > PS. Dear Christophe! Please do not think I criticize your implementation because I don't like it. There's anotgher solutions but I use yours. I just want make it better. Unfortunately, it takes time to catch up with code and I can't send you patch right today to check idea with UUID. -- SY, Alex Lukin RIPE NIC HDL: LEXA1-RIPE
