I'm working on a simple system that has a localizable domain model. Localizations should be stored in the database and retrieved on demand.
Each of the domain objects has the following lifecycle:
CREATED --> APPROVED --> ARCHIVED --> DELETED
Each of the lifecycle states is modelled using their own entity. So for example system has:
- CreatedProduct.class
- ApprovedProduct.class
- ArchivedProduct.class
When the object transitions to another state, it has all of his attributes copied into the next state object. The state changing mechanism is not reversible. It cannot happen that ApprovedProduct becomes CreatedProduct.
I've followed the pretty straight-forward way to introduce the localization. Each property inside the entity can be addressed in this way:
ObjectClass.[objectId].propertyName // plain property
ObjectClass.[objectId].collectionName[objectIdInsideCollection].propertyName // property inside child object
And on the DB level it looks like:
+------------+ +-----------+ +--------------------+
|Object | |Translation| |Translated Property |
+------------+1 *+-----------+1 *+--------------------+
| +-----+ language +-------+propertyCode |
| | | | |localizedValue |
+------------+ +-----------+ +--------------------+
With this approach I have some major problems:
- I'm assuming that the objectId will not ever change. But with described lifecycle this is not true. With each state transition system goes through all of the translations and modifies them.
- If any of the child objects are modified, system goes through the list of translations and modifies them accordingly
- I'm unable to track any translation using DB as foreign keys cannot be used with this approach
So finally to the question part:
- Is there a standard way of keeping localizations in the DB?
- How can my solution be improved / refactored to solve the major issues?
Aucun commentaire:
Enregistrer un commentaire