This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hi, I've been evaluating LightSpeed for past few hours and I couldn't resist temptation to try to use LightSpeed to map one of my hierarchical data models. It's not a model easily mappable to RDBMS, with or without O/R mapper. In fact it's so troublesome that in my solution I've taken different approach to persist and query it than to completely store it in RDBMS. However I wanted to give it a try, at least to see how far from being able to solve this problem LightSpeed currently is. The model is simple text document model. It contains four types of entities: Part, Section, Chapter, Document. Part is abstract base type, Section and Chapter derives from Part, Document derives from Chapter. Chapter can contain any number of parts. Document is the only Chapter which does not have parent chapter. Following LightSpeed designer model image says it all:
As clear from the model, entities are versioned, meaning they are never deleted, but instead, when updated, new version has to be created in database, version number increased and revision of the document which updated entity belongs to has to be increased as well. Versioning is really big complication but even without it it is not easy to map the model. Two types of operations must be supported: retrieval of the whole document (as quick as possible, optimally in one query) and operations on document parts based on their type and document they belong too (i.e. retrieve all sections which belong to document X and have property Y set to Z). I believe the first type of operation could be solved by eager loading/aggregates features of LightSpeed, although probably not in one query. The second type of operation is not readily possible with model on the image. N:1 relation from Part to Document would have to be added, and this relation would have to be kept in sync with the same relation on the parent chapter. This is what I do not know how to do in LightSpeed and I haven't found any other solution with LightSpeed to allow second type of operations which would not require traversing the hierarchy. If versioning is taken into account, each sub-part of chapter is identified not only by its ID but also its version. Unless there is some ingenious solution I'm not aware of, it requires composite keys and also M:N relationship from chapter to part, because one part can now belong to more chapters (to more versions of one chapter to be exact). That's even higher level and I don't know of any O/R mapper which can currently do it without writing custom queries. I hope this post makes some sense and can be of some value to LightSpeed developers, e.g. as a sample model in case they in the future decide to implement support for such scenario, or as two new O/R mapper challenges :-) Regards, Martin |
|
|
|
