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: svn commit: r406117 - /incubator/graffito/trunk/jcr/jcr-mapping/src/test/org/apache/portals/graffito/jcr/testmodel/interfaces/
Date Mon, 22 May 2006 21:52:50 GMT
On 5/23/06, Christophe Lombart <christophe.lombart@gmail.com> wrote:
> On 5/22/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
> >
> > I know that it is not perfect, but the user is aware of its existence.
> > Otherwise, if you add a mixin than the user may have big problems:
> >
> > 1/ convincing the admin to add the new type def
>
>
> This should be quite easy to convince the administrator to add a node type.
>
>

Frankly speaking it is not. I had huge problems when introducing new
mixin types with an existing repository. Even if the mixin stuff is
quite cool, sometimes this operation may become dangerous.

> 2/ change the migration tools to support this mixin
> >
> > The latest problem is quite serious, because currently the migration
> > tools are mostly inhouse tools, and you wouldn't like to have to
> > change it just to allow you to work with a lightweight mapping tool
> > like graffito.
>
>
> Can you give more details ? Is it not to recreate the mixin type ? Are you
> speaking about migrating from one specific JCR impl to another one ?
>

I am talking about JCR recovery. As you probably know, there are no
recovery tools available, so some companies are building such in-house
tools (f.e. we are planning to do so quite soon)

> The discriminator field has also some migration issue : Imagine that one day
> a new OCM tools is available but it doesn't use this discriminator field
> concept. Ideally you have to review all pojos and drop the discriminator
> field. What about if you decide to migrate from the nodeType per hierarchy
> to the node type per concrete class. You have also to review your pojos.
>

What you are naming here are big refactorings. If you think in terms
of RDBMS this are refactoring that you usually don't do.

> For me, this is more important to have pojos completely independent of the
> persistence strategy.
>

I think that once we require the path field there are not anymore
completely independent POJOs.

> Maybe we can try to combine both solution : no mixin type and no
> technical/discriminator field.
>

I will need to think about it.

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

> >
> >
> > On 5/23/06, Christophe Lombart <christophe.lombart@gmail.com> wrote:
> > > Alex,
> > >
> > > This solution is completly transparent for the developer :
> > > 1/ no specific field is required in the pojo which is excellent in point
> > of
> > > view object model.
> > > 2/ the mixin node type "graffito:discriminator" is added at runtime in
> > the
> > > target node. The Developer doesn't know this existence of this mixin
> > type.
> > >
> > > It only requires repository setting (add the mixin node type
> > > graffito:discriminator) but I'm agree it is not the perfect solution.
> > > I think the "discriminator field" is not also perfect. I don't like the
> > idea
> > > to add a technical attribute in the pojo.
> > >
> > > Let me think about it !
> > >
> > >
> > > On 5/22/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com>
> > wrote:
> > > >
> > > > Hi Chris!
> > > >
> > > > I just noticed this comment and I am not 100% I like the solution for
> > > > the discriminator mixin which seems obtrusive. It is like requiring a
> > > > class to implement a special interface just to make it work with
> > > > graffito and this is not good. The user must have the freedom to
> > > > define his nodetypes and create no dependencies upon graffito and for
> > > > this small thing it is really easy to configure hust a field name to
> > > > make it work.
> > > >
> > > > br,
> > > >
> > > > ./alex
> > > > --
> > > > .w( the_mindstorm )p.
> > > >
> > > >
> > > >
> > > > On 5/13/06, clombart@apache.org <clombart@apache.org> wrote:
> > > > > Author: clombart
> > > > > Date: Sat May 13 08:07:23 2006
> > > > > New Revision: 406117
> > > > >
> > > > > URL: http://svn.apache.org/viewcvs?rev=406117&view=rev
> > > > > Log:
> > > > > Add several modifications :
> > > > >
> > > > > * jcrNodeType is not mandatory.If not present the default value is
> > > > "nt:unstructured".
> > > > > * discriminator field descriptor was removed. Only the flag
> > > > discriminator is defined on the class descriptor.
> > > > >         If this flag is true, a mixin node type
> > "graffito:discriminator"
> > > > is added to the node.
> > > > >         This type contains one property to store the java classname
> > > > (graffito:classname).
> > > > >     With this implementation, the discriminator field is not
> > necessary.
> > > > So, the persistence mechanism is still transparent for the jaba beans.
> > > > >
> > > > > * Interface support : like the inheritance support, there are 2
> > > > differents strategies : node type per concrete class or per complete
> > > > hierarchy. The hierarchy strategy requires a discriminator node type.
> > > > >
> > > > > Added:
> > > > >
> > > >
> > incubator/graffito/trunk/jcr/jcr-mapping/src/test/org/apache/portals/graffito/jcr/testmodel/interfaces/
> > > > >
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Best regards,
> > >
> > > Christophe
> > >
> > >
> >
>
>
>
> --
> Best regards,
>
> Christophe
>
>

Mime
View raw message