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
|
I'm struggling with modelling "my world" with LightSpeed, and I'm wondering if what I want is possible or if there's some other way to solve this.
Is it possible to solve the modell above with Person and Organization being a part of the same table? I want those to be seperate tables with seperate classes, but what I want is the primary key (GUID) being in one table (GUIDTable) and when I make a person I want the guid to be added to guidtable, and then set as a foreignkey / primary key in Person as well. In advance, thanks!
-- Thomas |
|
|
LightSpeed does not support storing the ID in a separate table and
referring to it via an association. The ID must be part of the row
that is returned; and when creating entities LightSpeed expects to be able to send the ID as part of an INSERT statement on the entity table (except when using IdentityColumn). So the database structure you envisage will not be readily mappable using LightSpeed. If you use Single Table Inheritance, then Person and Organisation will indeed be part of the same table -- the table corresponding to the base class of the STI hierarchy (in this case, GUIDTable). If you want Person and Organisation to be different tables, then you can do it using Concrete Table Inheritance. But in this case each will have a separate ID column. You could possibly solve this using CRUD stored procedures to present LightSpeed with a "ID as part of the entity" view while using two separate tables under the surface at the database level. But this adds complexity and sacrifices flexibility. Another possibility, depending on your database, might be to use triggers to add the ID to GUIDTable whenever you add an entry to the Person or Organisation table. Could you say a bit more about why you want this particular database structure? If this is an existing database structure then LightSpeed may not be a good choice for mapping it; if this is a new database then why is it important to keep a separate central register of GUIDs? |
|
|
What I was describing is the "Class Table Inheritance"-pattern, and I'll try to describe why I want this pattern. The design is a new design, and our goal was to use Lightspeed "all the way" and using the model made in designer as part of the documentation for the design. And, now to the reason behind this; let's say we have the following tables: Code, User, Responsible [person] We want to be able to map codes both on users and responsible [people], and we know that there will be more classes / tables / areas that need the same (user being one area, responsible[person] being another). The reason behind this is that we want to easily add types of codes / tags that a user or responsible (or area in general) can have. I don't know if this becomes clear, but I'm unable to mockup the model right now.
|
|
|
Here's the current model we have: This model doesn't work with lightspeed because both "Enhet" and "Person" tries to use the same column in KodeMapper for keys (ObjID) but since they don't have a common parent for ObjID's this doesn't work very well. (Having the Class Table Inheritance for "Enhet" and "Person" would've solved this).
|
|
|
Unfortunately, we don't support class table inheritance. We have done some investigation into this, because several customers have asked for it, but our conclusion was that it was too difficult to tackle right now. So I'm afraid we will not be able to support your desired database design in the near future. Sorry! Could your desired functionality instead be accomplished by having associations from User and Responsible to Code, or an additional CodeType / Tag table, and eager-loading if performance is an issue? |
|
|
Is it possible to get a few hints on where to look for adding support, and then we might add the support ourselves? Will you accept a patch if we do such a thing? I mean, it's better to give it to you for maintenance than for us to keep patching official releases. Is this something planned for 3.0? Or isn't it added to any plans at all? It might be that we can solve it less elegantly another way, but I can't answer that without rethinking the design, tho. Preferred way would be the above one, tho... |
|
|
Class table inheritance is not currently in the plans for any future release. We are certainly willing to accept patches and we agree this would be much better than you creating your own fork (there's no way we could support a custom build of LightSpeed). We would be very happy to provide assistance and advice if you are interested in developing such a patch. It's probably best if you contact me by email (ivan @ the obvious domain name) and I can give you some pointers about where to hook in. I will also try to dig out my failed proof of concept code as this might help you get started at least on the Select side of things. |
|