You are viewing a plain text version of this content. The canonical link for it is here.
Posted to graffito-dev@incubator.apache.org by Alexandru Popescu <th...@gmail.com> on 2006/05/22 20:31:09 UTC
Re: svn commit: r406117 - /incubator/graffito/trunk/jcr/jcr-mapping/src/test/org/apache/portals/graffito/jcr/testmodel/interfaces/
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 <cl...@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/
>
>
Re: svn commit: r406117 - /incubator/graffito/trunk/jcr/jcr-mapping/src/test/org/apache/portals/graffito/jcr/testmodel/interfaces/
Posted by Alexandru Popescu <th...@gmail.com>.
On 5/23/06, Christophe Lombart <ch...@gmail.com> wrote:
> On 5/22/06, Alexandru Popescu <th...@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 <ch...@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 <th...@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 <cl...@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
>
>
Re: svn commit: r406117 - /incubator/graffito/trunk/jcr/jcr-mapping/src/test/org/apache/portals/graffito/jcr/testmodel/interfaces/
Posted by Christophe Lombart <ch...@gmail.com>.
On 5/22/06, Alexandru Popescu <th...@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.
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 ?
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.
For me, this is more important to have pojos completely independent of the
persistence strategy.
Maybe we can try to combine both solution : no mixin type and no
technical/discriminator field.
./alex
> --
> .w( the_mindstorm )p.
>
>
> On 5/23/06, Christophe Lombart <ch...@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 <th...@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 <cl...@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
Re: svn commit: r406117 - /incubator/graffito/trunk/jcr/jcr-mapping/src/test/org/apache/portals/graffito/jcr/testmodel/interfaces/
Posted by Alexandru Popescu <th...@gmail.com>.
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
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.
./alex
--
.w( the_mindstorm )p.
On 5/23/06, Christophe Lombart <ch...@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 <th...@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 <cl...@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
>
>
Re: svn commit: r406117 - /incubator/graffito/trunk/jcr/jcr-mapping/src/test/org/apache/portals/graffito/jcr/testmodel/interfaces/
Posted by Christophe Lombart <ch...@gmail.com>.
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 <th...@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 <cl...@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