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. 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 <[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
