incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandru Popescu <the.mindstorm.mailingl...@gmail.com>
Subject Re: mapping descriptor revisited
Date Sun, 05 Feb 2006 23:36:11 GMT
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 <the.mindstorm.mailinglist@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
> 


Mime
View raw message