There is special DataMapper plugin for for versioning: http://github.com/sam/dm-more/tree/master/dm-is-versioned
On Dec 15, 7:51 pm, Piotr Sarnacki <[email protected]> wrote: > Hi, > > I need to make some of my tables in database translated and in the > same time manage versioning of them. > > The standard approach (and by standard approach I mean the way that > I've seen in some plugins) to translations is to create > something_translations table. So if I have articles I need to create > articles_translations (that's how globalize for rails works). There is > also another way, just to add title_de, title_en, title_pl... etc. > fields but for me this is not an option - I just need to have elastic > system - adding new translation in particular language should be > possible without changing the database. > > It's quite easy to implement, but there comes another problem... > versioning. The standard approach is to create something_versions > table. In case of the above example it would end up with: > articles, articles_versions, articles_translations, > articles_translations_versions. Of course I can write some rake tasks > to automatically update extra tables but it seems too much for me :) > > I've been thinking about solutions for this problem and I came up with > some of them but I don't have enough experience to choose the best > solution. So maybe someone here with greater experience could help > me :) > > In case of translations: > 1. Self referential many to many - articles_translations table but not > as a copy of articles but as a join table. > > 2. A modification of above method. I have more than one table to > translate and for every model I have to create join table. This could > be avoided if a join table would be polymorphic. It would be easier to > use a plugin with such a feature - only one additional table and you > can easily translate all of your models. But it is also harder to > implement and probably slower. I don't know if that method makes > sense, even with huge number of models to translate. > > In case of versioning: > 1. If translations problem would be solved using one of above methods, > versioning standard approach could be used. As I have only one table > for articles and translations I can make only one table for versions: > articles_versions. But again - managing two tables for one resource is > not > fun ;] > > 2. One table with versioned_id field. Current version of article has > versioned_id set to NULL and its versions have versioned_id set to > original article id. With such a model it's as easy as: > has_many :versions, :foreign_key => :versioned_id, :class_name => > "Article" > > 3. Some kind of storage other than database. Yehuda Katz on his > presentation about datamapper was talking about YAML storage and > ability to easily add it to model. So maybe is would as simple as > saving versions as yaml files? It would not pollute original database > by additional table nor by additional records for versions. > > 4. Weird idea :) Create versions table and versioned_fields table. > With polymorphic associations any model could have many versions and > version could have many fields. > versions: > versionable_id > versionable_type > number > > versioned_fields: > version_id > value > > Value could be a special type (in datamapper), with format like: > "DateTime:Mon, 15 Dec 2008 20:22:07 +0100" or "Boolean:true" or > "String:Some string" or "BigDecimal:13.4566" > > There are only 2 additional tables for all of the models and database > is less polluted, but I can't say if it is good solution. > > Could you give me a feedback on those options or possibly tell me the > better ones? Which options would you choose for such a problem and why? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "merb" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/merb?hl=en -~----------~----~----~----~------~----~------~--~---
