Carsten Ziegeler wrote:
Yes, I more or less agree, but :) I can use ORM without mapping the PK,
for example in just reading use cases or I can even add new objects to
the database if the PK is auto generated. Updating and removing are the
things that do not work, but that's fine for me :)
However, the mapped bean most likely does have the pk mapped and has a
getter/setter for it. Hibernate, JPA, and JDO all require the id be set
and mapped within a bean. While a pk is not needed to do a lookup, a
bean must have one. Since UUID is not a required field, it seems that
the, albeit mutable, path is our best bet.
In addition I'm not sure if the analogy to a database really fits, in
JCR the path is "some kind of pk", but depending on your content model
and your use cases, the path of an object can change (while a pk in a
database never changes). Definitly a uuid would be the ultimate pk, but
obviously you don't want to force to have a uuid for each and every node.
So as a first step I propose to change the implementation of the OCM to
allow the reading use case even if the path field is not mapped (to be
honest I haven't checked if this is not working right now, perhaps it
already works, so we don't have to change it).
Second step would be to introduce an insert(String path, Object)
method to add an object at the given path.
That makes sense, I it doesn't feel right to me, but I don't have a good
argument against it. ;-)
In general, and I just talked with Felix about this offline, it would
be interesting/nice to have an interface that does not rely on a path
(string) as the input for methods, but on a Node. In many use cases I
already have the Node where I want to query or insert objects. So this
could simplify the handling.
Perhaps it would also be worth to split or minimize the current OCM
interface as things like versioning are not required for most use cases.
I think having a Node be exposed defeats the purpose of OCM. I see OCM
being used by clients that do not want/need to know what a node is but
should rather be using their domain specific language/model rather than
a generic one. Having the client know what a node is would be like them
knowing what a table and row are which, I feel, violates separation of
concerns.
-paddy
