You are viewing a plain text version of this content. The canonical link for it is here.

Posted to graffito-dev@incubator.apache.org by Alexandru Popescu <th...@gmail.com> on 2006/02/05 20:32:30 UTC

mapping descriptor revisited

Hi!

I finally had the time to revisit the mapping descriptor for class-descriptor, field-descriptor and
bean-descriptor. So far here are my conclusions:

A] class-descriptor

i/ jcrSuperTypes: doesn't seem to make sense to be used, cause we are not gonna create custom node
definitions. These are already defined within the repository and the information is contained in the
description of the jcrNodeType.

ii/ there is no way to declare that the node to be created has mixins. I would like to add a
jcrMixinTypes that specifies a comma separated list of mixins for the node to be created.

Adding mixins to a node at runtime is an allowed operation and I have good examples where this would
make sense.

iii/ there is no way to declare a custom converter. Currently a class-descriptor is
persisted/fetched by the ObjectConverterImpl. But considering the following suggestions (see
bean-descriptor) it would make sense to allow specifying a custom converter.

iv/ Currently there is not possible to provide multiple mappings for the same class. This may sound
weird in the first place, but I think there are scenarios where this would make sense. However, I
don't consider this a high priority.

B] field-descriptor

The following attributes used inside the mapping:

are duplicating the definition of a node type and cannot really be used (they are just informal). I
would suggest removing them.

C] bean-descriptor

The current bean-descriptor is able to handle only the scenario where the properties of the bean are
persisted on a direct subnode of the current node. As I pointed in a separate thread and Christophe
marked in the http://issues.apache.org/jira/browse/GRFT-54, the bean-descriptor should be able to
handle at least 3 scenarios:

a/ persisting the properties of the bean on the current node (a component bean)
b/ persisting the properties of the bean on a direct subnode of the current node (the current behavior)
c/ persisting the properties of the bean on subtree structure of the current node or an independent
node in the repository (consider GRFT-54 for the first part and a referenceable node for the 2nd part).

The modifications needed for this to work are quite simple:

a/ add a inline attribute with true/false values: if set to true, the bean properties are created as
properties of the current node

b/ add a converter attribute with a fully qualified name of a converter class, that will be
responsible for persisting/fetching the node. The API for this converter is a reduced version of the
current ObjectConverter interface. If not specified the converter to be used is the
ObjectConverterImpl (the current implementation).

I would also like to remove the following attributes from the mapping. They are duplicating a node
type definition and cannot be directly used:

As pointed previously, there are a few more things we need to define: review collection-descriptor,
define behavior for interface/inheritance (for queries, and persistence too).

However, once agreeing on the above points will allow me to implement the changes right away. Than
we can continue with the rest.

I would like to start doing the above changes right away, so I am eager to hear your opinions and
comments as soon as possible. Than we will have a new face of the OCM :-). Thanks in advance,

./alex
--
.w( the_mindstorm )p.

Re: mapping descriptor revisited

Posted by Christophe Lombart <ch...@gmail.com>.

+1 for the complete proposal.

--
Best regards,

Christophe

Re: mapping descriptor revisited

Posted by Alexandru Popescu <th...@gmail.com>.

Hi!

Sorry for missing the parts needed by Oliver. I will leave those untouched.

1/
A] class-descriptor ii/ mixins

Using the class diagram you sent me of graffito model: somebody can decide to have rankings/karma 
points of the stored content. This would be a numeric field stored on let's say Article, Document, 
Post. One approach would be to add this field to each node definition; but the correct approach 
considering JCR is to create a mixin: prefix:rankable that describes this ranking field. At a later 
step you can easily refactor by only touching this mixin, and keeping stable the other node definitions.


2/ converters: indeed field-descriptors may use a converter (replacing the current AtomicConverter). 
However, for the moment I cannot see a real good usage for it, so I would like to delay adding this 
till we really need it. What do you think?

3/ multiple mappings for the same class: the scenario would be quite simple: the application using 2 
repositories in which the same class User to be stored differently because of its different usage. 
Usually this problem is solved by creating fake subclasses of the User class, but another approach 
would be to add an alias to the class-descriptor.

4/ some clarification about bean-descriptor converter attribute: the only changes that should be 
done are:
- if inline=true than use a custom (provided by graffito) converter that writes/reads properties on 
the current node (and not on a subnode)
- if inline=false (default) and no converter is provided than use the current ObjectConverterImpl
- if inline=false and a converter is provided than delegate to that one the write/read operations.

Graffito will be only responsible to delegate to the custom converter. There is no way to create 
such a generic converter to cover GRFT-54 or reference scenarios. We must keep things simple, and 
make complex things possible. Indeed we may decide in time that we can provide some custom 
converters for well-defined node types (f.e. nt:file) but this is not something that really needs to 
be done. Every user will be able to create such a converter.

5/ about the rest of the points I will try to put some time next week and come up with some ideas.

For the moment, I would really like to have the above points agreed, so that I can implement some of 
them.

thanks,

./alex
--
.w( the_mindstorm )p.

#: Christophe Lombart changed the world a bit at a time by saying (astral date: 2/6/2006 12:21 AM) :#
> Hi Alex,
> 
> Here my comments :
> 
> On 2/5/06, Alexandru Popescu <th...@gmail.com> wrote:
> 
> 
>> Hi!
>>
>> I finally had the time to revisit the mapping descriptor for class-descriptor, field-descriptor and
>> bean-descriptor. So far here are my conclusions:
>>
>> A] class-descriptor
>>
>> i/ jcrSuperTypes: doesn't seem to make sense to be used, cause we are not gonna create custom node
>> definitions. These are already defined within the repository and the information is contained in the
>> description of the jcrNodeType.
>>
> 
> Oliver needs this information to create the JCR node types from our
> mapping files (see the subproject jcr-nodemanagement).  This is not a
> mandatory attribute.
> 
>> ii/ there is no way to declare that the node to be created has mixins. I would like to add a
>> jcrMixinTypes that specifies a comma separated list of mixins for the node to be created.
>>
>> Adding mixins to a node at runtime is an allowed operation and I have good examples where this would
>> make sense.
> 
> Please can you give me an example - thanks !
>>
>> iii/ there is no way to declare a custom converter. Currently a class-descriptor is
>> persisted/fetched by the ObjectConverterImpl. But considering the following suggestions (see
>> bean-descriptor) it would make sense to allow specifying a custom converter.
>>
> 
> Excellent ! +1 of course. The same can apply on the simple field-descriptors.
> 
>> iv/ Currently there is not possible to provide multiple mappings for the same class. This may sound
>> weird in the first place, but I think there are scenarios where this would make sense. However, I
>> don't consider this a high priority.
>>
> 
> I'm just curious to know the scenarios you are thinking about :-)
> 
>> B] field-descriptor
>>
>> The following attributes used inside the mapping:
>>
>> jcrAutoCreated (true | false) "false"
>> jcrOnParentVersion (COPY | VERSION | INITIALIZE | COMPUTE | IGNORE | ABORT) "COPY"
>> jcrMandatory (true | false) "false"
>>
>> are duplicating the definition of a node type and cannot really be used (they are just informal). I
>> would suggest removing them.
>>
> 
> Oliver needs this information to create the JCR node types from our
> mapping files (see the subproject jcr-nodemanagement).  They are not
> mandatory attributes.
> 
>> C] bean-descriptor
>>
>> The current bean-descriptor is able to handle only the scenario where the properties of the bean are
>> persisted on a direct subnode of the current node. As I pointed in a separate thread and Christophe
>> marked in the http://issues.apache.org/jira/browse/GRFT-54, the bean-descriptor should be able to
>> handle at least 3 scenarios:
>>
>> a/ persisting the properties of the bean on the current node (a component bean)
>> b/ persisting the properties of the bean on a direct subnode of the current node (the current behavior)
>> c/ persisting the properties of the bean on subtree structure of the current node or an independent
>> node in the repository (consider GRFT-54 for the first part and a referenceable node for the 2nd part).
>>
>> The modifications needed for this to work are quite simple:
>>
>> a/ add a inline attribute with true/false values: if set to true, the bean properties are created as
>> properties of the current node
>>
> 
> Cool !
> 
>> b/ add a converter attribute with a fully qualified name of a converter class, that will be
>> responsible for persisting/fetching the node. The API for this converter is a reduced version of the
>> current ObjectConverter interface. If not specified the converter to be used is the
>> ObjectConverterImpl (the current implementation).
>>
>>
> 
> If I understand, you will create new ObjectConverter implementations
> (one for each scenarios b (already exist), c.1 (GRFT-54) and c.2
> (reference).
> If yes, is it possible to create a generic ObjectConverter
> implementations that support GRFT-54 ?
> 
>> I would also like to remove the following attributes from the mapping. They are duplicating a node
>> type definition and cannot be directly used:
>>
>> jcrAutoCreated (true | false) "false"
>> jcrOnParentVersion (COPY | VERSION | INITIALIZE | COMPUTE | IGNORE | ABORT) "COPY"
>> jcrSameNameSiblings (true | false) "false"
>>
>>
> 
> Oliver needs this information to create the JCR node types from our
> mapping files (see the subproject jcr-nodemanagement).  There are not
> mandatory attributes.
> 
>> As pointed previously, there are a few more things we need to define: review collection-descriptor,
> 
> I'm also curious to know more on that.
> 
>> define behavior for interface/inheritance (for queries, and persistence too).
>>
> 
> Yes. those points are very important. Personnally, I don't see an
> interest to persist interface & ancestor. +1 for queries
> 
>> However, once agreeing on the above points will allow me to implement the changes right away. Than
>> we can continue with the rest.
>>
>> I would like to start doing the above changes right away, so I am eager to hear your opinions and
>> comments as soon as possible. Than we will have a new face of the OCM :-). Thanks in advance,
> 
> Thanks  for this nice work.
> 
> --
> Best regards,
> 
> Christophe
>

Re: mapping descriptor revisited

Posted by Christophe Lombart <ch...@gmail.com>.

Hi Alex,

Here my comments :

On 2/5/06, Alexandru Popescu <th...@gmail.com> wrote:


> Hi!
>
> I finally had the time to revisit the mapping descriptor for class-descriptor, field-descriptor and
> bean-descriptor. So far here are my conclusions:
>
> A] class-descriptor
>
> i/ jcrSuperTypes: doesn't seem to make sense to be used, cause we are not gonna create custom node
> definitions. These are already defined within the repository and the information is contained in the
> description of the jcrNodeType.
>

Oliver needs this information to create the JCR node types from our
mapping files (see the subproject jcr-nodemanagement).  This is not a
mandatory attribute.

> ii/ there is no way to declare that the node to be created has mixins. I would like to add a
> jcrMixinTypes that specifies a comma separated list of mixins for the node to be created.
>
> Adding mixins to a node at runtime is an allowed operation and I have good examples where this would
> make sense.

Please can you give me an example - thanks !
>
> iii/ there is no way to declare a custom converter. Currently a class-descriptor is
> persisted/fetched by the ObjectConverterImpl. But considering the following suggestions (see
> bean-descriptor) it would make sense to allow specifying a custom converter.
>

Excellent ! +1 of course. The same can apply on the simple field-descriptors.

> iv/ Currently there is not possible to provide multiple mappings for the same class. This may sound
> weird in the first place, but I think there are scenarios where this would make sense. However, I
> don't consider this a high priority.
>

I'm just curious to know the scenarios you are thinking about :-)

> B] field-descriptor
>
> The following attributes used inside the mapping:
>
> jcrAutoCreated (true | false) "false"
> jcrOnParentVersion (COPY | VERSION | INITIALIZE | COMPUTE | IGNORE | ABORT) "COPY"
> jcrMandatory (true | false) "false"
>
> are duplicating the definition of a node type and cannot really be used (they are just informal). I
> would suggest removing them.
>

Oliver needs this information to create the JCR node types from our
mapping files (see the subproject jcr-nodemanagement).  They are not
mandatory attributes.

> C] bean-descriptor
>
> The current bean-descriptor is able to handle only the scenario where the properties of the bean are
> persisted on a direct subnode of the current node. As I pointed in a separate thread and Christophe
> marked in the http://issues.apache.org/jira/browse/GRFT-54, the bean-descriptor should be able to
> handle at least 3 scenarios:
>
> a/ persisting the properties of the bean on the current node (a component bean)
> b/ persisting the properties of the bean on a direct subnode of the current node (the current behavior)
> c/ persisting the properties of the bean on subtree structure of the current node or an independent
> node in the repository (consider GRFT-54 for the first part and a referenceable node for the 2nd part).
>
> The modifications needed for this to work are quite simple:
>
> a/ add a inline attribute with true/false values: if set to true, the bean properties are created as
> properties of the current node
>

Cool !

> b/ add a converter attribute with a fully qualified name of a converter class, that will be
> responsible for persisting/fetching the node. The API for this converter is a reduced version of the
> current ObjectConverter interface. If not specified the converter to be used is the
> ObjectConverterImpl (the current implementation).
>
>

If I understand, you will create new ObjectConverter implementations
(one for each scenarios b (already exist), c.1 (GRFT-54) and c.2
(reference).
If yes, is it possible to create a generic ObjectConverter
implementations that support GRFT-54 ?

> I would also like to remove the following attributes from the mapping. They are duplicating a node
> type definition and cannot be directly used:
>
> jcrAutoCreated (true | false) "false"
> jcrOnParentVersion (COPY | VERSION | INITIALIZE | COMPUTE | IGNORE | ABORT) "COPY"
> jcrSameNameSiblings (true | false) "false"
>
>

Oliver needs this information to create the JCR node types from our
mapping files (see the subproject jcr-nodemanagement).  There are not
mandatory attributes.

> As pointed previously, there are a few more things we need to define: review collection-descriptor,

I'm also curious to know more on that.

> define behavior for interface/inheritance (for queries, and persistence too).
>

Yes. those points are very important. Personnally, I don't see an
interest to persist interface & ancestor. +1 for queries

> However, once agreeing on the above points will allow me to implement the changes right away. Than
> we can continue with the rest.
>
> I would like to start doing the above changes right away, so I am eager to hear your opinions and
> comments as soon as possible. Than we will have a new face of the OCM :-). Thanks in advance,

Thanks  for this nice work.

--
Best regards,

Christophe

Re: mapping descriptor revisited

Posted by Christophe Lombart <ch...@gmail.com>.

Cool !



On 2/8/06, Alexandru Popescu <th...@gmail.com> wrote:
> Hi!
>
> All the features considered in this mail were implemented, (tested) and are in the SVN head.
>
> Later this week, I will look into collection-descriptors and interface/inheritance. For the moment,
> I cannot promise anything, but I really hope to find a  couple of hours to do it.
>
> cheers,
>
> ./alex
> --
> .w( the_mindstorm )p.
>
> #: Alexandru Popescu changed the world a bit at a time by saying (astral date: 2/5/2006 10:32 PM) :#
> > Hi!
> >
> > I finally had the time to revisit the mapping descriptor for class-descriptor, field-descriptor and
> > bean-descriptor. So far here are my conclusions:
> >
> > A] class-descriptor
> >
> > i/ jcrSuperTypes: doesn't seem to make sense to be used, cause we are not gonna create custom node
> > definitions. These are already defined within the repository and the information is contained in the
> > description of the jcrNodeType.
> >
> > ii/ there is no way to declare that the node to be created has mixins. I would like to add a
> > jcrMixinTypes that specifies a comma separated list of mixins for the node to be created.
> >
> > Adding mixins to a node at runtime is an allowed operation and I have good examples where this would
> > make sense.
> >
> > iii/ there is no way to declare a custom converter. Currently a class-descriptor is
> > persisted/fetched by the ObjectConverterImpl. But considering the following suggestions (see
> > bean-descriptor) it would make sense to allow specifying a custom converter.
> >
> > iv/ Currently there is not possible to provide multiple mappings for the same class. This may sound
> > weird in the first place, but I think there are scenarios where this would make sense. However, I
> > don't consider this a high priority.
> >
> > B] field-descriptor
> >
> > The following attributes used inside the mapping:
> >
> > jcrAutoCreated (true | false) "false"
> > jcrOnParentVersion (COPY | VERSION | INITIALIZE | COMPUTE | IGNORE | ABORT) "COPY"
> > jcrMandatory (true | false) "false"
> >
> > are duplicating the definition of a node type and cannot really be used (they are just informal). I
> > would suggest removing them.
> >
> > C] bean-descriptor
> >
> > The current bean-descriptor is able to handle only the scenario where the properties of the bean are
> > persisted on a direct subnode of the current node. As I pointed in a separate thread and Christophe
> > marked in the http://issues.apache.org/jira/browse/GRFT-54, the bean-descriptor should be able to
> > handle at least 3 scenarios:
> >
> > a/ persisting the properties of the bean on the current node (a component bean)
> > b/ persisting the properties of the bean on a direct subnode of the current node (the current behavior)
> > c/ persisting the properties of the bean on subtree structure of the current node or an independent
> > node in the repository (consider GRFT-54 for the first part and a referenceable node for the 2nd part).
> >
> > The modifications needed for this to work are quite simple:
> >
> > a/ add a inline attribute with true/false values: if set to true, the bean properties are created as
> > properties of the current node
> >
> > b/ add a converter attribute with a fully qualified name of a converter class, that will be
> > responsible for persisting/fetching the node. The API for this converter is a reduced version of the
> > current ObjectConverter interface. If not specified the converter to be used is the
> > ObjectConverterImpl (the current implementation).
> >
> >
> > I would also like to remove the following attributes from the mapping. They are duplicating a node
> > type definition and cannot be directly used:
> >
> > jcrAutoCreated (true | false) "false"
> > jcrOnParentVersion (COPY | VERSION | INITIALIZE | COMPUTE | IGNORE | ABORT) "COPY"
> > jcrSameNameSiblings (true | false) "false"
> >
> >
> > As pointed previously, there are a few more things we need to define: review collection-descriptor,
> > define behavior for interface/inheritance (for queries, and persistence too).
> >
> > However, once agreeing on the above points will allow me to implement the changes right away. Than
> > we can continue with the rest.
> >
> > I would like to start doing the above changes right away, so I am eager to hear your opinions and
> > comments as soon as possible. Than we will have a new face of the OCM :-). Thanks in advance,
> >
> > ./alex
> > --
> > .w( the_mindstorm )p.
> >
> >
>
>


--
Best regards,

Christophe

Re: mapping descriptor revisited

Posted by Alexandru Popescu <th...@gmail.com>.

Hi!

All the features considered in this mail were implemented, (tested) and are in the SVN head.

Later this week, I will look into collection-descriptors and interface/inheritance. For the moment, 
I cannot promise anything, but I really hope to find a  couple of hours to do it.

cheers,

./alex
--
.w( the_mindstorm )p.

#: Alexandru Popescu changed the world a bit at a time by saying (astral date: 2/5/2006 10:32 PM) :#
> Hi!
> 
> I finally had the time to revisit the mapping descriptor for class-descriptor, field-descriptor and 
> bean-descriptor. So far here are my conclusions:
> 
> A] class-descriptor
> 
> i/ jcrSuperTypes: doesn't seem to make sense to be used, cause we are not gonna create custom node 
> definitions. These are already defined within the repository and the information is contained in the 
> description of the jcrNodeType.
> 
> ii/ there is no way to declare that the node to be created has mixins. I would like to add a 
> jcrMixinTypes that specifies a comma separated list of mixins for the node to be created.
> 
> Adding mixins to a node at runtime is an allowed operation and I have good examples where this would 
> make sense.
> 
> iii/ there is no way to declare a custom converter. Currently a class-descriptor is 
> persisted/fetched by the ObjectConverterImpl. But considering the following suggestions (see 
> bean-descriptor) it would make sense to allow specifying a custom converter.
> 
> iv/ Currently there is not possible to provide multiple mappings for the same class. This may sound 
> weird in the first place, but I think there are scenarios where this would make sense. However, I 
> don't consider this a high priority.
> 
> B] field-descriptor
> 
> The following attributes used inside the mapping:
> 
> jcrAutoCreated (true | false) "false"
> jcrOnParentVersion (COPY | VERSION | INITIALIZE | COMPUTE | IGNORE | ABORT) "COPY"
> jcrMandatory (true | false) "false"
> 
> are duplicating the definition of a node type and cannot really be used (they are just informal). I 
> would suggest removing them.
> 
> C] bean-descriptor
> 
> The current bean-descriptor is able to handle only the scenario where the properties of the bean are 
> persisted on a direct subnode of the current node. As I pointed in a separate thread and Christophe 
> marked in the http://issues.apache.org/jira/browse/GRFT-54, the bean-descriptor should be able to 
> handle at least 3 scenarios:
> 
> a/ persisting the properties of the bean on the current node (a component bean)
> b/ persisting the properties of the bean on a direct subnode of the current node (the current behavior)
> c/ persisting the properties of the bean on subtree structure of the current node or an independent 
> node in the repository (consider GRFT-54 for the first part and a referenceable node for the 2nd part).
> 
> The modifications needed for this to work are quite simple:
> 
> a/ add a inline attribute with true/false values: if set to true, the bean properties are created as 
> properties of the current node
> 
> b/ add a converter attribute with a fully qualified name of a converter class, that will be 
> responsible for persisting/fetching the node. The API for this converter is a reduced version of the 
> current ObjectConverter interface. If not specified the converter to be used is the 
> ObjectConverterImpl (the current implementation).
> 
> 
> I would also like to remove the following attributes from the mapping. They are duplicating a node 
> type definition and cannot be directly used:
> 
> jcrAutoCreated (true | false) "false"
> jcrOnParentVersion (COPY | VERSION | INITIALIZE | COMPUTE | IGNORE | ABORT) "COPY"
> jcrSameNameSiblings (true | false) "false"
> 
> 
> As pointed previously, there are a few more things we need to define: review collection-descriptor, 
> define behavior for interface/inheritance (for queries, and persistence too).
> 
> However, once agreeing on the above points will allow me to implement the changes right away. Than 
> we can continue with the rest.
> 
> I would like to start doing the above changes right away, so I am eager to hear your opinions and 
> comments as soon as possible. Than we will have a new face of the OCM :-). Thanks in advance,
> 
> ./alex
> --
> .w( the_mindstorm )p.
> 
>