[xwiki-devs] why hasn't the class deletion been implemented?
This might seem stupid but what are the limitations in class/object deletion? br Pascal
Pascal Voitot wrote:
This might seem stupid but what are the limitations in class/object deletion?
We don't know what to do with the data. Adding a property is simple, existing objects will not have a property and it will be added when the object is saved. But when you delete a property, what do we do? Leave it there? Delete it from all the objects? If we keep it there, it will be "shadowed", as the persistence layer will not know that it exists. More, if we add back that property with the same name and another type, we'll have errors because we'll have two instances with the same identifier in two places (this is what happened when switching number types or the multiselect metaproperty of a list property). If we remove it, then we'll completely remove a lot of data. And is a warning enough for that? Probably we need a mass rollback utility that is able to revert bulk changes. My take is that we should remove the data, but what do others think? -- Sergiu Dumitriu http://purl.org/net/sergiu/
That's what I think... In a ideal world, removing a class or a property should imply removing associated instances naturally... Another idea...One question: are classes and properties versioned as documents? I mean, if you modify a class, is it possible to keep the previous version and keep existing objects as instantiations of the older version and then new objects will be instantiations of the newer version of the class? We could also propose an object to be translated into the newer version with some risks. In this case, it could be simple to modify or remove properties of a class even if it would bring some complexity also... Then the last problem would be class deletion which would be more violent and would need some strong warnings because objects would be deleted definitely... in this case, a kind of temporary bin could be interesting... Pascal On Tue, Mar 18, 2008 at 10:56 AM, Sergiu Dumitriu <[email protected]> wrote:
Pascal Voitot wrote:
This might seem stupid but what are the limitations in class/object deletion?
We don't know what to do with the data. Adding a property is simple, existing objects will not have a property and it will be added when the object is saved. But when you delete a property, what do we do? Leave it there? Delete it from all the objects?
If we keep it there, it will be "shadowed", as the persistence layer will not know that it exists. More, if we add back that property with the same name and another type, we'll have errors because we'll have two instances with the same identifier in two places (this is what happened when switching number types or the multiselect metaproperty of a list property).
If we remove it, then we'll completely remove a lot of data. And is a warning enough for that? Probably we need a mass rollback utility that is able to revert bulk changes.
My take is that we should remove the data, but what do others think? -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Yes but we need tons of warning in case properties are deleted. If class are deleted this is even more problematic as this can make a lot of deletion. For versioning, what we do is we store in the XML of each object the definition of the class at the time the object was saved. This means we can build the class as it was before we actually load the object. Now I'm pretty sure we don't really make use of that. Ludovic Pascal Voitot wrote:
That's what I think... In a ideal world, removing a class or a property should imply removing associated instances naturally... Another idea...One question: are classes and properties versioned as documents? I mean, if you modify a class, is it possible to keep the previous version and keep existing objects as instantiations of the older version and then new objects will be instantiations of the newer version of the class? We could also propose an object to be translated into the newer version with some risks. In this case, it could be simple to modify or remove properties of a class even if it would bring some complexity also... Then the last problem would be class deletion which would be more violent and would need some strong warnings because objects would be deleted definitely... in this case, a kind of temporary bin could be interesting...
Pascal
On Tue, Mar 18, 2008 at 10:56 AM, Sergiu Dumitriu <[email protected] <mailto:[email protected]>> wrote:
Pascal Voitot wrote: > This might seem stupid but what are the limitations in class/object > deletion? >
We don't know what to do with the data. Adding a property is simple, existing objects will not have a property and it will be added when the object is saved. But when you delete a property, what do we do? Leave it there? Delete it from all the objects?
If we keep it there, it will be "shadowed", as the persistence layer will not know that it exists. More, if we add back that property with the same name and another type, we'll have errors because we'll have two instances with the same identifier in two places (this is what happened when switching number types or the multiselect metaproperty of a list property).
If we remove it, then we'll completely remove a lot of data. And is a warning enough for that? Probably we need a mass rollback utility that is able to revert bulk changes.
My take is that we should remove the data, but what do others think? -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] <mailto:[email protected]> http://lists.xwiki.org/mailman/listinfo/devs
------------------------------------------------------------------------
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
ok I see But do we agree that we shall have a class/mechanism deletion somewhere? (in fact I agree with myself about that at least because I'm frustrated not to be able to delete the classes I don't need anymore :)) I'm not sure about something: did you intend to give to the concept of "class" about the same "generic" extend as the concept of "class" in any OO language? Is a class a kind of descriptor of entities with their own properties and relations to other entities? or is a class only a convenience for gathering properties and creating objects with these properties? If XWiki classes are real classes (I think they are) then it would be nice to push the concepts as far as possible... Moreover, with XE (that I don't have installed yet), it would be nice to be able to manage classes directly and to have refactoring features :)... Pascal On Tue, Mar 18, 2008 at 12:52 PM, Ludovic Dubost <[email protected]> wrote:
Yes but we need tons of warning in case properties are deleted. If class are deleted this is even more problematic as this can make a lot of deletion.
For versioning, what we do is we store in the XML of each object the definition of the class at the time the object was saved. This means we can build the class as it was before we actually load the object.
Now I'm pretty sure we don't really make use of that.
Ludovic
Pascal Voitot wrote:
That's what I think... In a ideal world, removing a class or a property should imply removing associated instances naturally... Another idea...One question: are classes and properties versioned as documents? I mean, if you modify a class, is it possible to keep the previous version and keep existing objects as instantiations of the older version and then new objects will be instantiations of the newer version of the class? We could also propose an object to be translated into the newer version with some risks. In this case, it could be simple to modify or remove properties of a class even if it would bring some complexity also... Then the last problem would be class deletion which would be more violent and would need some strong warnings because objects would be deleted definitely... in this case, a kind of temporary bin could be interesting...
Pascal
On Tue, Mar 18, 2008 at 10:56 AM, Sergiu Dumitriu <[email protected] <mailto:[email protected]>> wrote:
Pascal Voitot wrote: > This might seem stupid but what are the limitations in class/object > deletion? >
We don't know what to do with the data. Adding a property is simple, existing objects will not have a property and it will be added when the object is saved. But when you delete a property, what do we do? Leave it there? Delete it from all the objects?
If we keep it there, it will be "shadowed", as the persistence layer will not know that it exists. More, if we add back that property with the same name and another type, we'll have errors because we'll have two instances with the same identifier in two places (this is what happened when switching number types or the multiselect metaproperty of a list property).
If we remove it, then we'll completely remove a lot of data. And is a warning enough for that? Probably we need a mass rollback utility that is able to revert bulk changes.
My take is that we should remove the data, but what do others think? -- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] <mailto:[email protected]> http://lists.xwiki.org/mailman/listinfo/devs
------------------------------------------------------------------------
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
We have thought about the capability of having class heritage.. but it's not so easy to implement.. Want to work on it ? Ludovic Pascal Voitot wrote:
ok I see But do we agree that we shall have a class/mechanism deletion somewhere? (in fact I agree with myself about that at least because I'm frustrated not to be able to delete the classes I don't need anymore :))
I'm not sure about something: did you intend to give to the concept of "class" about the same "generic" extend as the concept of "class" in any OO language? Is a class a kind of descriptor of entities with their own properties and relations to other entities? or is a class only a convenience for gathering properties and creating objects with these properties? If XWiki classes are real classes (I think they are) then it would be nice to push the concepts as far as possible... Moreover, with XE (that I don't have installed yet), it would be nice to be able to manage classes directly and to have refactoring features :)...
Pascal
On Tue, Mar 18, 2008 at 12:52 PM, Ludovic Dubost <[email protected] <mailto:[email protected]>> wrote:
Yes but we need tons of warning in case properties are deleted. If class are deleted this is even more problematic as this can make a lot of deletion.
For versioning, what we do is we store in the XML of each object the definition of the class at the time the object was saved. This means we can build the class as it was before we actually load the object.
Now I'm pretty sure we don't really make use of that.
Ludovic
Pascal Voitot wrote: > That's what I think... > In a ideal world, removing a class or a property should imply removing > associated instances naturally... > Another idea...One question: are classes and properties versioned as > documents? I mean, if you modify a class, is it possible to keep the > previous version and keep existing objects as instantiations of the > older version and then new objects will be instantiations of the newer > version of the class? We could also propose an object to be > translated into the newer version with some risks. > In this case, it could be simple to modify or remove properties of a > class even if it would bring some complexity also... > Then the last problem would be class deletion which would be more > violent and would need some strong warnings because objects would be > deleted definitely... in this case, a kind of temporary bin could be > interesting... > > Pascal > > On Tue, Mar 18, 2008 at 10:56 AM, Sergiu Dumitriu <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > Pascal Voitot wrote: > > This might seem stupid but what are the limitations in class/object > > deletion? > > > > We don't know what to do with the data. Adding a property is simple, > existing objects will not have a property and it will be added > when the > object is saved. But when you delete a property, what do we do? > Leave it > there? Delete it from all the objects? > > If we keep it there, it will be "shadowed", as the persistence layer > will not know that it exists. More, if we add back that property with > the same name and another type, we'll have errors because we'll > have two > instances with the same identifier in two places (this is what > happened > when switching number types or the multiselect metaproperty of a list > property). > > If we remove it, then we'll completely remove a lot of data. And is a > warning enough for that? Probably we need a mass rollback utility that > is able to revert bulk changes. > > My take is that we should remove the data, but what do others think? > -- > Sergiu Dumitriu > http://purl.org/net/sergiu/ > _______________________________________________ > devs mailing list > [email protected] <mailto:[email protected]> <mailto:[email protected] <mailto:[email protected]>> > http://lists.xwiki.org/mailman/listinfo/devs > > > ------------------------------------------------------------------------ > > _______________________________________________ > devs mailing list > [email protected] <mailto:[email protected]> > http://lists.xwiki.org/mailman/listinfo/devs >
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
_______________________________________________ devs mailing list [email protected] <mailto:[email protected]> http://lists.xwiki.org/mailman/listinfo/devs
------------------------------------------------------------------------
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Ludovic Dubost Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost
Ludovic Dubost wrote:
We have thought about the capability of having class heritage.. but it's not so easy to implement.. Want to work on it ?
Indeed, it is not so easy. Marta and I worked on it about a year ago, and we had a working prototype. But the changes were too big to commit all at once, so the code remained on a local computer while waiting for the new Data component for XWiki.
Ludovic
Pascal Voitot wrote:
ok I see But do we agree that we shall have a class/mechanism deletion somewhere? (in fact I agree with myself about that at least because I'm frustrated not to be able to delete the classes I don't need anymore :))
I'm not sure about something: did you intend to give to the concept of "class" about the same "generic" extend as the concept of "class" in any OO language? Is a class a kind of descriptor of entities with their own properties and relations to other entities? or is a class only a convenience for gathering properties and creating objects with these properties? If XWiki classes are real classes (I think they are) then it would be nice to push the concepts as far as possible... Moreover, with XE (that I don't have installed yet), it would be nice to be able to manage classes directly and to have refactoring features :)...
Pascal
On Tue, Mar 18, 2008 at 12:52 PM, Ludovic Dubost <[email protected] <mailto:[email protected]>> wrote:
Yes but we need tons of warning in case properties are deleted. If class are deleted this is even more problematic as this can make a lot of deletion.
For versioning, what we do is we store in the XML of each object the definition of the class at the time the object was saved. This means we can build the class as it was before we actually load the object.
Now I'm pretty sure we don't really make use of that.
Ludovic
Pascal Voitot wrote: > That's what I think... > In a ideal world, removing a class or a property should imply removing > associated instances naturally... > Another idea...One question: are classes and properties versioned as > documents? I mean, if you modify a class, is it possible to keep the > previous version and keep existing objects as instantiations of the > older version and then new objects will be instantiations of the newer > version of the class? We could also propose an object to be > translated into the newer version with some risks. > In this case, it could be simple to modify or remove properties of a > class even if it would bring some complexity also... > Then the last problem would be class deletion which would be more > violent and would need some strong warnings because objects would be > deleted definitely... in this case, a kind of temporary bin could be > interesting... > > Pascal > > On Tue, Mar 18, 2008 at 10:56 AM, Sergiu Dumitriu <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > Pascal Voitot wrote: > > This might seem stupid but what are the limitations in class/object > > deletion? > > > > We don't know what to do with the data. Adding a property is simple, > existing objects will not have a property and it will be added > when the > object is saved. But when you delete a property, what do we do? > Leave it > there? Delete it from all the objects? > > If we keep it there, it will be "shadowed", as the persistence layer > will not know that it exists. More, if we add back that property with > the same name and another type, we'll have errors because we'll > have two > instances with the same identifier in two places (this is what > happened > when switching number types or the multiselect metaproperty of a list > property). > > If we remove it, then we'll completely remove a lot of data. And is a > warning enough for that? Probably we need a mass rollback utility that > is able to revert bulk changes. > > My take is that we should remove the data, but what do others think?
-- Sergiu Dumitriu http://purl.org/net/sergiu/
I really like class/object+scripting features and I would be pleased to give some help... I can propose to begin with a study about class/properties/objects deletion so that I really understand everything about the model and its problems and then if my work pleases you (and me also:)), let's go further about some deeper issues... if you already worked on it, maybe you could provide me with some of your conclusions (if not secret:)) so that I don't go in wrong directions you may have already encountered. Moreover, I have seen some mails concerning new Data Model. I don't know much about that but I will look at it also because it might modify the Class model... What do you think about that? Pascal On Tue, Mar 18, 2008 at 4:39 PM, Sergiu Dumitriu <[email protected]> wrote:
Ludovic Dubost wrote:
We have thought about the capability of having class heritage.. but it's not so easy to implement.. Want to work on it ?
Indeed, it is not so easy. Marta and I worked on it about a year ago, and we had a working prototype. But the changes were too big to commit all at once, so the code remained on a local computer while waiting for the new Data component for XWiki.
Ludovic
Pascal Voitot wrote:
ok I see But do we agree that we shall have a class/mechanism deletion somewhere? (in fact I agree with myself about that at least because I'm frustrated not to be able to delete the classes I don't need anymore :))
I'm not sure about something: did you intend to give to the concept of "class" about the same "generic" extend as the concept of "class" in any OO language? Is a class a kind of descriptor of entities with their own properties and relations to other entities? or is a class only a convenience for gathering properties and creating objects with these properties? If XWiki classes are real classes (I think they are) then it would be nice to push the concepts as far as possible... Moreover, with XE (that I don't have installed yet), it would be nice to be able to manage classes directly and to have refactoring features :)...
Pascal
On Tue, Mar 18, 2008 at 12:52 PM, Ludovic Dubost <[email protected] <mailto:[email protected]>> wrote:
Yes but we need tons of warning in case properties are deleted. If class are deleted this is even more problematic as this can make a lot of deletion.
For versioning, what we do is we store in the XML of each object the definition of the class at the time the object was saved. This means we can build the class as it was before we actually load the object.
Now I'm pretty sure we don't really make use of that.
Ludovic
Pascal Voitot wrote: > That's what I think... > In a ideal world, removing a class or a property should imply removing > associated instances naturally... > Another idea...One question: are classes and properties versioned as > documents? I mean, if you modify a class, is it possible to keep the > previous version and keep existing objects as instantiations of the > older version and then new objects will be instantiations of the newer > version of the class? We could also propose an object to be > translated into the newer version with some risks. > In this case, it could be simple to modify or remove properties of a > class even if it would bring some complexity also... > Then the last problem would be class deletion which would be more > violent and would need some strong warnings because objects would be > deleted definitely... in this case, a kind of temporary bin could be > interesting... > > Pascal > > On Tue, Mar 18, 2008 at 10:56 AM, Sergiu Dumitriu <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > Pascal Voitot wrote: > > This might seem stupid but what are the limitations in class/object > > deletion? > > > > We don't know what to do with the data. Adding a property is simple, > existing objects will not have a property and it will be added > when the > object is saved. But when you delete a property, what do we do? > Leave it > there? Delete it from all the objects? > > If we keep it there, it will be "shadowed", as the persistence layer > will not know that it exists. More, if we add back that property with > the same name and another type, we'll have errors because we'll > have two > instances with the same identifier in two places (this is what > happened > when switching number types or the multiselect metaproperty of a list > property). > > If we remove it, then we'll completely remove a lot of data. And is a > warning enough for that? Probably we need a mass rollback utility that > is able to revert bulk changes. > > My take is that we should remove the data, but what do others think?
-- Sergiu Dumitriu http://purl.org/net/sergiu/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (3)
-
Ludovic Dubost -
Pascal Voitot -
Sergiu Dumitriu