Comments on: Versioning System http://eksperimental.net/blog/2007/08/08/versioning-system/ development log of art.gnome.org 3 Thu, 20 Nov 2008 01:43:03 +0000 http://wordpress.org/?v=2.2.1 By: Bruno Santos http://eksperimental.net/blog/2007/08/08/versioning-system/#comment-117 Bruno Santos Thu, 09 Aug 2007 13:53:39 +0000 http://eksperimental.net/blog/2007/08/08/versioning-system/#comment-117 I already think I'm making this way too complex to what it is going to be used. Plus I've already coded the MP model and I think it does the job well. The idea of the Versioning system is just to maintain all the versions users submit related. And probably do some neat map tree way of showing that evolution. I already think I’m making this way too complex to what it is going to be used.

Plus I’ve already coded the MP model and I think it does the job well.

The idea of the Versioning system is just to maintain all the versions users submit related. And probably do some neat map tree way of showing that evolution.

]]> By: knipknap http://eksperimental.net/blog/2007/08/08/versioning-system/#comment-116 knipknap Thu, 09 Aug 2007 12:33:32 +0000 http://eksperimental.net/blog/2007/08/08/versioning-system/#comment-116 Well, unless you are planning to create one table per user, that would be 100.000 for *all* users. Of course, you could create multiple nested sets within one table, but then your database has to support constraints over more than one column. You could also NOT use constraints, but that would be a hack. Provided you are using MySQL, I am pretty sure that using multiple Nested Sets in one table is bound to get you into trouble sooner or later. Anyway, the nested set would already no longer work as soon as you want to be able to delete specific single versions or branches from the history. Believe me, the MP algorithm is definitely what you want. Look for the "tefinch_message" table in this file: http://cvs.gna.org/cvsweb/tefinch/mysql_matpath.sql?rev=1.10;cvsroot=tefinch for an example MySQL model. Beware, there are some tricky issues to consider in MySQL (like, MySQL strips trailing spaces even from varbinary fields). The corresponding code that loads the database is here: http://cvs.gna.org/cvsweb/tefinch/src/services/forumdb.class.php?rev=1.8;cvsroot=tefinch Now that I think about it, did you consider using a simple filesystem structure instead? Remember that reading a BLOB from a database is probably 10 times slower than reading a file directly from the filesystem. Well, unless you are planning to create one table per user, that would be 100.000 for *all* users.

Of course, you could create multiple nested sets within one table, but then your database has to support constraints over more than one column. You could also NOT use constraints, but that would be a hack.

Provided you are using MySQL, I am pretty sure that using multiple Nested Sets in one table is bound to get you into trouble sooner or later.

Anyway, the nested set would already no longer work as soon as you want to be able to delete specific single versions or branches from the history. Believe me, the MP algorithm is definitely what you want.

Look for the “tefinch_message” table in this file:

http://cvs.gna.org/cvsweb/tefinch/mysql_matpath.sql?rev=1.10;cvsroot=tefinch

for an example MySQL model. Beware, there are some tricky issues to consider in MySQL (like, MySQL strips trailing spaces even from varbinary fields). The corresponding code that loads the database is here:

http://cvs.gna.org/cvsweb/tefinch/src/services/forumdb.class.php?rev=1.8;cvsroot=tefinch

Now that I think about it, did you consider using a simple filesystem structure instead? Remember that reading a BLOB from a database is probably 10 times slower than reading a file directly from the filesystem.

]]> By: Bruno Santos http://eksperimental.net/blog/2007/08/08/versioning-system/#comment-115 Bruno Santos Wed, 08 Aug 2007 12:13:30 +0000 http://eksperimental.net/blog/2007/08/08/versioning-system/#comment-115 knipknap: Well, I'm not expecting a user to have 100.000 works in ago :p Nonetheless, I'll give a look in the "materialized path". Thanks! knipknap:
Well, I’m not expecting a user to have 100.000 works in ago :p

Nonetheless, I’ll give a look in the “materialized path”.

Thanks!

]]> By: knipknap http://eksperimental.net/blog/2007/08/08/versioning-system/#comment-114 knipknap Wed, 08 Aug 2007 08:30:32 +0000 http://eksperimental.net/blog/2007/08/08/versioning-system/#comment-114 What you describe as "Modified Preorder Tree Transversal" sounds lot like a nested set. The problem with nested sets is that they do not scale, because inserts are expensive. If you expect more than, say 100.000 records in that table, I am pretty sure that this model is NOT suitable for a.g.o. One solution includes a nested set with "insert holes", where the neighbors are not increased by +1 but by a value of (for example) +1000, such that you do not have to increase all node values on each and every insert operation. But IMO a much better model would be the "materialized path". This also allows for branching very easily. -Samuel What you describe as “Modified Preorder Tree Transversal” sounds lot like a nested set. The problem with nested sets is that they do not scale, because inserts are expensive. If you expect more than, say 100.000 records in that table, I am pretty sure that this model is NOT suitable for a.g.o.

One solution includes a nested set with “insert holes”, where the neighbors are not increased by +1 but by a value of (for example) +1000, such that you do not have to increase all node values on each and every insert operation.

But IMO a much better model would be the “materialized path”. This also allows for branching very easily.

-Samuel

]]>