[OCM] Making the path field optional?

[Carsten Ziegeler <cz...@apache.org>]

Hi,

I'm currently trying to map some beans to jcr using OCM. It seems that
currently a mapping is only possible, if my bean has a path field 
containing the path of the bean in the repository. Or if I want to add a 
new bean to the repo, I've to set the path on the bean first in order to 
tell OCM where to store it.

I don't know if this has been discussed before, but I think this
requirement somehow ties the beans to jcr which is not nice :) I'm 
wondering if there isn't a better way?

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [OCM] Making the path field optional?

["Padraic I. Hannon" <pi...@wasabicowboy.com>]

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

Re: [OCM] Making the path field optional?

[Christophe Lombart <ch...@gmail.com>]

On Jan 22, 2008 8:57 AM, Carsten Ziegeler <cz...@apache.org> wrote:

>
> 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).


ok for the reading stuff . This is not really complex to implemented in the
current code but ...
In my point of view, there are more "retrieve" use cases that will need to
get the path after retrieving content. eg. after selecting one content in a
list, do something with it.


>
> Second step would be to introduce an insert(String path, Object) method
> to add an object at the given path.


Like Paddy, I have not strong arguments but  is there a big different  with
the current situation ?  setting the path as argument or  in the object
attribute provide almost the same result :-)


>
> 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.



Completly agree with Paddy.
For me, the main OCM goal is to make an abstraction on the JCR technology
:-). This goal is very important for many applications.

If you need unstructured content, the JCR model is very powefull but if you
are managing domain specific content, OCM becomes more interesting. In this
case, the developers do not care about nodes.



> 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.


Good idea. please make a jira issue.


Christophe

Re: [OCM] Making the path field optional?

[Carsten Ziegeler <cz...@apache.org>]

Padraic I. Hannon wrote:
> A path is pretty fundamental to jcr, not having one would be like not 
> having a primary key for a bean retrieved from an orm solution. As most 
> orm's require beans to specify a pk I do not see the problem with ocm 
> doing the same. Trying to work around this I think would lead the ocm to 
> making all sorts of assumptions including all objects are created via 
> the ocm when there are times when working (esp. it would seem with 
> client/server stuff) that the object may not have been originally 
> retrieved via the ocm (I'm thinking value object patterns).
> 
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 :)
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.

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.

WDYT?

Carsten

-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [OCM] Making the path field optional?

["Padraic I. Hannon" <pi...@wasabicowboy.com>]

A path is pretty fundamental to jcr, not having one would be like not 
having a primary key for a bean retrieved from an orm solution. As most 
orm's require beans to specify a pk I do not see the problem with ocm 
doing the same. Trying to work around this I think would lead the ocm to 
making all sorts of assumptions including all objects are created via 
the ocm when there are times when working (esp. it would seem with 
client/server stuff) that the object may not have been originally 
retrieved via the ocm (I'm thinking value object patterns).

-paddy

Re: [OCM] Making the path field optional?

[Carsten Ziegeler <cz...@apache.org>]

Christophe Lombart wrote:
> On Jan 21, 2008 3:06 PM, Carsten Ziegeler <cz...@apache.org> wrote:
> 
>>
>> Now, it's not a big deal to add the string property to my bean, but
>> still it doesn't feel nice :)
>> So the addition of insert(String path, Object object) and not requiring
>> a path field when reading beans from jcr would be sufficient for my use
>> case :)
>>
> 
> IMHO, supporting both solutions will add more confusion to the users.
> 
> I would like to suggest to keep the current OCM API and the mandatory path
> attribute
> or
> remove the mandatory path attribute and refactor OCM API in order to add the
> path as argument of some methods.
> 
If I looked correctly there are only three methods which are problematic 
: insert, update, remove(Object).

Now, insert can simply be changed by adding the path argument.
So, this leaves us with update and remove, both using an Object - now 
this object should be an object that has been retrieved previously from 
the OCM, so perhaps we could use this fact for the implementation?

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [OCM] Making the path field optional?

[Christophe Lombart <ch...@gmail.com>]

On Jan 21, 2008 3:06 PM, Carsten Ziegeler <cz...@apache.org> wrote:

>
>
> Now, it's not a big deal to add the string property to my bean, but
> still it doesn't feel nice :)
> So the addition of insert(String path, Object object) and not requiring
> a path field when reading beans from jcr would be sufficient for my use
> case :)
>

IMHO, supporting both solutions will add more confusion to the users.

I would like to suggest to keep the current OCM API and the mandatory path
attribute
or
remove the mandatory path attribute and refactor OCM API in order to add the
path as argument of some methods.

Christophe


> Carsten
> --
> Carsten Ziegeler
> cziegeler@apache.org
>

Re: [OCM] Making the path field optional?

[Carsten Ziegeler <cz...@apache.org>]

Christophe Lombart wrote:
> When we started the first OCM prototype in 2005, there were 2 solutions :
> - Use a "path" attribute in each pojo .
> or
> - Use the path  as an argument in many ObjectContentManager methods like
> ocm.insert(String path, Object object)
> 
> The first solution has been selected because the path is good candidate for
> an object id.
> 
> 
>> I don't know if this has been discussed before, but I think this
>> requirement somehow ties the beans to jcr which is not nice :) I'm
>> wondering if there isn't a better way?
>>
> 
> you are right. Maybe it is a bad influence from the ORM technologies :-) .
> I mean,  having an  id like the path or an UUID is maybe not necessary in
> our OCM framework. We can review if there is another alternative.
> 
Hmm, yes - I can imagine that it might be difficult to get everything 
working without the path (id).

Currently I have the use case where I just want to store a bean at a 
specific path - the bean itself does not care about the path and I want 
to query these beans - but I don't need the path in the result.

Now, it's not a big deal to add the string property to my bean, but 
still it doesn't feel nice :)
So the addition of insert(String path, Object object) and not requiring 
a path field when reading beans from jcr would be sufficient for my use 
case :)

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [OCM] Making the path field optional?

[Christophe Lombart <ch...@gmail.com>]

When we started the first OCM prototype in 2005, there were 2 solutions :
- Use a "path" attribute in each pojo .
or
- Use the path  as an argument in many ObjectContentManager methods like
ocm.insert(String path, Object object)

The first solution has been selected because the path is good candidate for
an object id.


> I don't know if this has been discussed before, but I think this
> requirement somehow ties the beans to jcr which is not nice :) I'm
> wondering if there isn't a better way?
>

you are right. Maybe it is a bad influence from the ORM technologies :-) .
I mean,  having an  id like the path or an UUID is maybe not necessary in
our OCM framework. We can review if there is another alternative.

br,
Christophe

Re: [OCM] Making the path field optional?

[Carsten Ziegeler <cz...@apache.org>]

Felix Meschberger wrote:
> Hi Carsten,
> 
> Yes this has been discussed before - actually just recently [1].
> 
Ups, totally oversaw this - sorry :(

> And yes, currently, OCM requires a path field to be able to do the
> mapping. This is comparable to the IDs used by other mapping products.
>
Yes, but depending on my use case, I'm not required to have id 
attributes - like if I'm only reading stuff from a db, that's not required.

And I never liked the mapping tools where I was forced to have an id 
field :)

Carsten
-- 
Carsten Ziegeler
cziegeler@apache.org

Re: [OCM] Making the path field optional?

[Felix Meschberger <fm...@gmail.com>]

Hi Carsten,

Yes this has been discussed before - actually just recently [1].

And yes, currently, OCM requires a path field to be able to do the
mapping. This is comparable to the IDs used by other mapping products.

Regards
Felix

[1] http://www.mail-archive.com/dev@jackrabbit.apache.org/msg09621.html

Am Montag, den 21.01.2008, 14:29 +0100 schrieb Carsten Ziegeler:
> Hi,
> 
> I'm currently trying to map some beans to jcr using OCM. It seems that
> currently a mapping is only possible, if my bean has a path field 
> containing the path of the bean in the repository. Or if I want to add a 
> new bean to the repo, I've to set the path on the bean first in order to 
> tell OCM where to store it.
> 
> I don't know if this has been discussed before, but I think this
> requirement somehow ties the beans to jcr which is not nice :) I'm 
> wondering if there isn't a better way?
> 
> Carsten