incubator-graffito-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexandru Popescu <>
Subject Re: JCR Mapping enhancement request(s)
Date Mon, 02 Jan 2006 10:03:46 GMT
#: Christophe Lombart changed the world a bit at a time by saying on  1/2/2006 11:47 AM :#
> Hi Alex,
> Happy new year ! It is nice to see you here :-)
> Well, I have no special comments to your suggestions. Your proposed
> patches will be welcome. Can you add them in the Graffito jira
> application ?  Concerning your third suggestion : yes there is a plan
> to add a cache service in this mapping framework.
> Do you plan to use this mapping tools in Magnolia ?
> Kind regards,
> Christophe

Hi Christophe and thanks for your quick answer.

1/ I will create 2 JIRAs for the mentioned points and let you know immediately.

2/ I am planning to use the mapping tools with my product that uses Magnolia. Later on, if
things proove to work well, Magnolia may become a good place to use it, cause it may bring
a new 
dimension of features. Still, there are a few mapping scenarios that are not covered (even
currently I haven't reached them in my project, but I think some of them I will). My intention
is to 
follow the Hibernate mapping strategies and see which ones can be applied successfully to
JCR. As 
you probably know, at this moment Hibernate offers quite a good vision on mapping strategies.

Please let me know what are your intentions regarding JCR-mapping module, so that we may be
able to 
  focus on the same track ;-).


.w( the_mindstorm )p.

> On 1/2/06, Alexandru Popescu <> wrote:
>> Hi!
>> This is my first mail to this list and I would like to wish everybody here a Happy
New Year!
>> I have started to try using Graffito JCR Mapping into the project I am working now.
I've been
>> investigating the code so far and I would like to ask you about the possibility of
adding a few
>> enhancements.
>> 1/ new attribute in the mapping DTD.
>> I would like to have an additional fieldType=fully_qualified_class_name in field-descriptor
and also
>> bean-descriptor. This would bring 2 benefits:
>> i/ the possibility to generate a source class from the mapping
>> ii/ the possibility to remove an inspection step (f.e. in ObjectConverterImpl).
>> If you agree with this I can provide the needed patch quite immediately :-).
>> 2/ AtomicTypeConverters
>> The atomic type converters are dependent on a ValueFactory which can be retrieved
from the current
>> Session. I would like to ask if it is possible to add a setValueFactory(ValueFactory)
to the
>> AtomicTypeConvert interface and make all the default implementors have both a no-arg
constructor and
>> the current one.
>> This will allow an easy creation of converters (((AtomicTypeConverter)
>> converterClass.newInstance()).setValueFactory() instead of the longer version using
the actual
>> constructor).
>> Once again if you agree with this change I can provide the needed patch quite immediately.
>> 3/ Reflective access
>> Another thing that I am looking for (but not so urgent) would be to optimize the
reflective access,
>> by caching some of the information (so that the beanutils are not used every time).
Currently the
>> reflection performance is quite good, and I don't expect to see a big impact on this,
>> considering large sets of objects the impact may be important.
>> cheers,
>> ./alex
>> --
>> .w( the_mindstorm )p.
>> =======================================================
>> Me      :            Alexandru Popescu
>> Contact :     the_mindstorm[at]evolva[dot]ro
>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>> Projects:
>>    TestNG   [co-author]:
>>    Magnolia [committer]:
>>    WebWork  [committer]:
>> =======================================================
> !DSPAM:43b8f6e0670361126616474!

View raw message