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 am in the process of upgrading an application to use Lightspeed, the database assigned to this app, has over 100 tables. The key fields for these tables vary, most are integer using the built-in SQL Identity type. However, many use end-user entered strings as the key field, also using these string primary keys as part of a primary key - foreign key relationship. When I look in the LS settnigs for a table, there seems to be no option to accomodate this. Is this possible with LS, or do I need to go back to the customer and tell him we need to recreate the entire database? And manually convert all the data in his existing clients systems? |
|
|
This is not a scenario we handle particularly well I'm afraid. There are two separate issues here: 1. Business meaningful IDs LightSpeed expects to be in control of IDs, but in your scenario you need the user to be able to specify the ID. You can handle this by overriding the GeneratedId() function. LightSpeed calls GeneratedId() when it needs to allocate an ID to an entity -- basically when the new entity joins a unit of work for the first time. The default is of course to us the current identity method, but you can override it to return the user-entered string or whatever. Please note that GeneratedId() gets called only once during the entire lifecycle of an entity. You need to be ready with the ID as soon as the entity joins a UOW: you will not get a second chance to set it later on! 2. IDs that are also foreign keys This is basically not supported at the moment. We have implemented support for this in the composite key scenario, but (paradoxically) not in the simple key scenario. So at the moment you have two options for this: a. Manually create a property to do the lookup e.g. partial class MyEntity { b. Implement your ID as a composite key with only one field in the composite. Then use the new ForeignKeyFieldAttribute to specify that one field as the FK for your association. See http://www.mindscape.co.nz/forums/Post.aspx?ThreadID=2990&PostID=9499 for info about this. Neither of these is ideal, I know, so I will try to extend the PK-as-FK support to cover non-composite keys, but we are a bit busy at the moment and I can't make any promises on when we might get round to this. |
|
|
Ivan, thanks again for a prompt reply. I have taken a look at other forum entries regarding the use of GeneratedID(), and I am a little confused. I notice from the earlier entries that the GeneratedID() must return a value, however, when I create a partial class to one of the entities, and create the override, I cannot find a way to see the value entered in the form for the ID by the user? I am pressuming this is the value that I must return? Also, as I stated, we have over one hundred tables, with maybe 50% using user entered key values. Is there a way to perform this override at a higher level, where it can know the table selected identity method, and either use the base.GeneratedId() or the user enter ID accordingly. As a request for future features, can I suggest an additional Identity method of User Entered? Thanks |
|
|
You need to provide that value to the entity ready for when GeneratedId() is called. A common pattern is to use a transient field, e.g. public class MyEntity : Entity<string> { Yes, you can perform this override in a common base class, but you'll need to distinguish between entities with user-entered identities and entities with auto-allocated identities. The implementation might look something like this: public class EntityBase<TId> { Here I'm assuming that all string-keyed entities have user-entered identities, and all others have auto-allocated identities. Your logic may have to be more discriminating of course! |
|
|
Thanks for this example. This has given me some food for thought. I will have a little practice and see what happens. |
|
|
IDs that are also foreign keys - is it still not implemented? |
|
|
It can be implemented using ForeignKeyFieldAttribute. See: http://www.mindscape.co.nz/blog/index.php/2010/06/17/many-to-many-associations-and-composite-keys-in-lightspeed/ (This example is written around composite keys but I believe it will work for simple keys by specifying a path of "Id" on its own.) |
|