[xwiki-devs] New "Foreign Key" property
I'm proposing to implement a new property type: A foreign key, analogous to the concept in relational databases. Together with custom mapping, a property like this would make it possible to use Xwiki as a frontend for a relational database, while making full use of the wikis capabilities(configurability, history, etc). The implementation would look similar to the existing "Database list" on the outside, but it would make a lot more use of the databases features. If A links to B, and someone deletes B the reference in A would either be set to null, or the delete would be stopped, depending on the configuration. It would also make it possible to adress associated objects directly in hql. The basic functionality can be emulated using DBList(adding a property to one object by choosing from existing instances of another class), but this is not useful if one wants to have "real" foreign key behaviour in the wiki and the underlying DB. If there is a demand for this I will be happy to contribute a patch once I am done, and I will try make the code nice enough to submit. Otherwise I will probably just make it as a hack to meet the exact need that I have... Thomas
I had the same idea a few weeks ago. But my idea was not only to allow using foreign key but to create directly a "BaseObjectProperty" which would be represented by a foreign key in the DB but which would be mapped in HQL as a BaseObject... Something like: "select obj.linkedobj from BaseObject as obj" This would be really really powerful... I have been linking 2 objects using a LongProperty to represent the foreign key but I can't write direct HQL requests... regards Pascal On Thu, Oct 23, 2008 at 5:11 PM, Thomas McColgan < [email protected]> wrote:
I'm proposing to implement a new property type: A foreign key, analogous to the concept in relational databases. Together with custom mapping, a property like this would make it possible to use Xwiki as a frontend for a relational database, while making full use of the wikis capabilities(configurability, history, etc). The implementation would look similar to the existing "Database list" on the outside, but it would make a lot more use of the databases features. If A links to B, and someone deletes B the reference in A would either be set to null, or the delete would be stopped, depending on the configuration. It would also make it possible to adress associated objects directly in hql.
The basic functionality can be emulated using DBList(adding a property to one object by choosing from existing instances of another class), but this is not useful if one wants to have "real" foreign key behaviour in the wiki and the underlying DB. If there is a demand for this I will be happy to contribute a patch once I am done, and I will try make the code nice enough to submit. Otherwise I will probably just make it as a hack to meet the exact need that I have...
Thomas _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Hi, Thomas. I think it is a good idea. It would be very useful for xwiki. I propose ReferencePropertyClass (contains reference target (object,document,attachment), cascade delete options and other configurations) ObjectReferenceProperty (reference to BaseObject) DocumentReferenceProperty (if needed. reference to XWikiDocument) as name of these properties. I think "Foreign key" is too technical name for this. Please create a jira issue (new feature) and attach patches. Thanks Thomas McColgan wrote:
I'm proposing to implement a new property type: A foreign key, analogous to the concept in relational databases. Together with custom mapping, a property like this would make it possible to use Xwiki as a frontend for a relational database, while making full use of the wikis capabilities(configurability, history, etc). The implementation would look similar to the existing "Database list" on the outside, but it would make a lot more use of the databases features. If A links to B, and someone deletes B the reference in A would either be set to null, or the delete would be stopped, depending on the configuration. It would also make it possible to adress associated objects directly in hql.
The basic functionality can be emulated using DBList(adding a property to one object by choosing from existing instances of another class), but this is not useful if one wants to have "real" foreign key behaviour in the wiki and the underlying DB. If there is a demand for this I will be happy to contribute a patch once I am done, and I will try make the code nice enough to submit. Otherwise I will probably just make it as a hack to meet the exact need that I have...
Thomas _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Artem Melentyev
fully agree with that! if need any support, don't hesitate to ask... will try to find a few minutes... On Fri, Oct 24, 2008 at 6:20 AM, Artem Melentyev <[email protected]>wrote:
Hi, Thomas.
I think it is a good idea. It would be very useful for xwiki.
I propose ReferencePropertyClass (contains reference target (object,document,attachment), cascade delete options and other configurations) ObjectReferenceProperty (reference to BaseObject) DocumentReferenceProperty (if needed. reference to XWikiDocument) as name of these properties. I think "Foreign key" is too technical name for this.
Please create a jira issue (new feature) and attach patches.
Thanks
Thomas McColgan wrote:
I'm proposing to implement a new property type: A foreign key, analogous to the concept in relational databases. Together with custom mapping, a property like this would make it possible to use Xwiki as a frontend for a relational database, while making full use of the wikis capabilities(configurability, history, etc). The implementation would look similar to the existing "Database list" on the outside, but it would make a lot more use of the databases features. If A links to B, and someone deletes B the reference in A would either be set to null, or the delete would be stopped, depending on the configuration. It would also make it possible to adress associated objects directly in hql.
The basic functionality can be emulated using DBList(adding a property to one object by choosing from existing instances of another class), but this is not useful if one wants to have "real" foreign key behaviour in the wiki and the underlying DB. If there is a demand for this I will be happy to contribute a patch once I am done, and I will try make the code nice enough to submit. Otherwise I will probably just make it as a hack to meet the exact need that I have...
Thomas _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Artem Melentyev _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
OK, I am slowly getting there. The status now is that it defaults to setting the value to null if the "parent" is deleted. The best thing would be if it was possible to have a cascade delete and maybe even refuse behavior, too. I'm not sure how to implement that, though... I don't even know if that is possible without a big rewrite. I guess I would need a kind of hook into the deleting routine of all objects... Any ideas? Thomas On Sat, Oct 25, 2008 at 12:03 PM, Pascal Voitot <[email protected]> wrote:
fully agree with that! if need any support, don't hesitate to ask... will try to find a few minutes...
On Fri, Oct 24, 2008 at 6:20 AM, Artem Melentyev <[email protected]>wrote:
Hi, Thomas.
I think it is a good idea. It would be very useful for xwiki.
I propose ReferencePropertyClass (contains reference target (object,document,attachment), cascade delete options and other configurations) ObjectReferenceProperty (reference to BaseObject) DocumentReferenceProperty (if needed. reference to XWikiDocument) as name of these properties. I think "Foreign key" is too technical name for this.
Please create a jira issue (new feature) and attach patches.
Thanks
Thomas McColgan wrote:
I'm proposing to implement a new property type: A foreign key, analogous to the concept in relational databases. Together with custom mapping, a property like this would make it possible to use Xwiki as a frontend for a relational database, while making full use of the wikis capabilities(configurability, history, etc). The implementation would look similar to the existing "Database list" on the outside, but it would make a lot more use of the databases features. If A links to B, and someone deletes B the reference in A would either be set to null, or the delete would be stopped, depending on the configuration. It would also make it possible to adress associated objects directly in hql.
The basic functionality can be emulated using DBList(adding a property to one object by choosing from existing instances of another class), but this is not useful if one wants to have "real" foreign key behaviour in the wiki and the underlying DB. If there is a demand for this I will be happy to contribute a patch once I am done, and I will try make the code nice enough to submit. Otherwise I will probably just make it as a hack to meet the exact need that I have...
Thomas _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Artem Melentyev _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
Don't understand exactly what's your problem? you can't cascade delete? On Mon, Oct 27, 2008 at 5:00 PM, Thomas McColgan < [email protected]> wrote:
OK, I am slowly getting there. The status now is that it defaults to setting the value to null if the "parent" is deleted. The best thing would be if it was possible to have a cascade delete and maybe even refuse behavior, too. I'm not sure how to implement that, though... I don't even know if that is possible without a big rewrite. I guess I would need a kind of hook into the deleting routine of all objects...
Any ideas?
Thomas
On Sat, Oct 25, 2008 at 12:03 PM, Pascal Voitot <[email protected]> wrote:
fully agree with that! if need any support, don't hesitate to ask... will try to find a few minutes...
On Fri, Oct 24, 2008 at 6:20 AM, Artem Melentyev <[email protected] wrote:
Hi, Thomas.
I think it is a good idea. It would be very useful for xwiki.
I propose ReferencePropertyClass (contains reference target (object,document,attachment), cascade delete options and other configurations) ObjectReferenceProperty (reference to BaseObject) DocumentReferenceProperty (if needed. reference to XWikiDocument) as name of these properties. I think "Foreign key" is too technical name for this.
Please create a jira issue (new feature) and attach patches.
Thanks
Thomas McColgan wrote:
I'm proposing to implement a new property type: A foreign key, analogous to the concept in relational databases. Together with custom mapping, a property like this would make it possible to use Xwiki as a frontend for a relational database, while making full use of the wikis capabilities(configurability, history, etc). The implementation would look similar to the existing "Database list" on the outside, but it would make a lot more use of the databases features. If A links to B, and someone deletes B the reference in A would either be set to null, or the delete would be stopped, depending on the configuration. It would also make it possible to adress associated objects directly in hql.
The basic functionality can be emulated using DBList(adding a property to one object by choosing from existing instances of another class), but this is not useful if one wants to have "real" foreign key behaviour in the wiki and the underlying DB. If there is a demand for this I will be happy to contribute a patch once I am done, and I will try make the code nice enough to submit. Otherwise I will probably just make it as a hack to meet the exact need that I have...
Thomas _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Artem Melentyev _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
sorry, my terminology was a bit messed up. I want to implement the following behaviours: If a referenced object is deleted: 1. cascade: also delete all items/objects that contain references to the deleted object. 2. set null: this is what is happening now, though only when the property is being queried. in the meanwhile the DB is in a potentially inconsistent state. 3. restrict: refuse to delete an object as long as it is being referenced from somewhere else. the features are described in more detail here: http://dev.mysql.com/doc/refman/5.0/en/innodb-foreign-key-constraints.html Cheers, Thomas On Tue, Oct 28, 2008 at 3:36 PM, Pascal Voitot <[email protected]> wrote:
Don't understand exactly what's your problem? you can't cascade delete?
On Mon, Oct 27, 2008 at 5:00 PM, Thomas McColgan < [email protected]> wrote:
OK, I am slowly getting there. The status now is that it defaults to setting the value to null if the "parent" is deleted. The best thing would be if it was possible to have a cascade delete and maybe even refuse behavior, too. I'm not sure how to implement that, though... I don't even know if that is possible without a big rewrite. I guess I would need a kind of hook into the deleting routine of all objects...
Any ideas?
Thomas
On Sat, Oct 25, 2008 at 12:03 PM, Pascal Voitot <[email protected]> wrote:
fully agree with that! if need any support, don't hesitate to ask... will try to find a few minutes...
On Fri, Oct 24, 2008 at 6:20 AM, Artem Melentyev <[email protected] wrote:
Hi, Thomas.
I think it is a good idea. It would be very useful for xwiki.
I propose ReferencePropertyClass (contains reference target (object,document,attachment), cascade delete options and other configurations) ObjectReferenceProperty (reference to BaseObject) DocumentReferenceProperty (if needed. reference to XWikiDocument) as name of these properties. I think "Foreign key" is too technical name for this.
Please create a jira issue (new feature) and attach patches.
Thanks
Thomas McColgan wrote:
I'm proposing to implement a new property type: A foreign key, analogous to the concept in relational databases. Together with custom mapping, a property like this would make it possible to use Xwiki as a frontend for a relational database, while making full use of the wikis capabilities(configurability, history, etc). The implementation would look similar to the existing "Database list" on the outside, but it would make a lot more use of the databases features. If A links to B, and someone deletes B the reference in A would either be set to null, or the delete would be stopped, depending on the configuration. It would also make it possible to adress associated objects directly in hql.
The basic functionality can be emulated using DBList(adding a property to one object by choosing from existing instances of another class), but this is not useful if one wants to have "real" foreign key behaviour in the wiki and the underlying DB. If there is a demand for this I will be happy to contribute a patch once I am done, and I will try make the code nice enough to submit. Otherwise I will probably just make it as a hack to meet the exact need that I have...
Thomas _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Artem Melentyev _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
participants (3)
-
Artem Melentyev -
Pascal Voitot -
Thomas McColgan