On 5/23/06, Christophe Lombart <[EMAIL PROTECTED]> wrote:
On 5/22/06, Alexandru Popescu <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> 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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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
