Re: mapping descriptor revisited

[Alexandru Popescu]

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 <[EMAIL PROTECTED]> 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