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 -~----------~----~----~----~------~----~------~--~---
