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 fostering an Idea and wondered if Lightspeed was up to the Challenge? I have not found the solution yet but thought I would ask. I would like to have support for a local fallback database incase a server database is not available. My problem is when I take an Entity from one UnitOfWork(Database) to another I need to change the EntityState depending on the state of the entity to that database. Do you think there is a solution for this? I would need to keep primary keys mostly the same in both databases. Except new items in the local database (not on the server) would need special primary keys that would not interfere with the server keys. But I can not set the primary keys mannually. And then to top it off all the relations ids and foreign keys would need to be syncd. Perhaps an Easy trigger for the UnitofWork would be when an entity is added with the Add method that it does not have an EntityState of New the UOW could check if the entity exists in the database first the do an update or insert as needed. Thus preserving Id syncs from server to Local. As for local to server perhaps persisting negative Ids to a local database on new items or perhaps just using a GUID would prevent any ID conflict. Your thoughts would be great. |
|
|
|
|
This sounds more like a database replication or sync scenario - of which generally you could solve using the underlying database providers own capabilities (e.g. Sync Framework for SQL Server), could you give some context around the problem you are trying to solve here? :)
Jeremy |
|
|
|
|
I thought you might say that. Because you are right (mostly). I would like to provide a permanent local cache(of unchanging entities) for my application to speed up queries. I would like to provide persistence of items not saved (save them locally then post to a server when a user presses save) to solve reentry of data when a program crashes or database is unavailable. Also solving the problem of running a query and getting the databases results but not the local unsaved results. I would like to handle sync manually on my own. I have thought about what I actually need and I think I could do all this and more if I could set the Id column manually. Im not asking for the Id property to become writable. I am asking for a way to set the Id property in some situations. Make us jump through some hoops to set it and throw exceptions when we dont meet those hoops or scenarios. That way only those who know why they are setting the Id will do it. Convention over Configuration is great and meets 90% of my needs. |
|
|
|
|
Oh this all started when I was trying to create a local copy database for unit testing purposes. I tried all the migration wizards I could think of. None of them worked 100% not even on Schema. So I created the local database by and tried to sync my model. Well Ivan is working on fixing that problem. So I re-created the Schema by hand and then said hey why not use LightSpeed to copy my data from one database to the other. And then I realized I couldnt and all these other scenarios I was fostering were impossible with the current tools LightSpeed have. |
|
|
|
|
We do provide a limited way to control the Id property. When LightSpeed needs to allocate an ID for an entity, it calls that entity's GeneratedId() method. By default, this delegates to the context's identity method, e.g. KeyTable or IdentityColumn. But you can override this method to specify your own ID. This is not as flexible as a full SetId() method, which we are reluctant to provide because it is potentially very complex to deal with the possibility of an entity ID changing after it has been set. But it does allow IDs to be controlled up to the point of allocation, i.e. usually up to the point where you call SaveChanges (and only on entities that are New). For example have a transient field on your entity, set that, and then in your GeneratedId() method return the value of the transient field. If you want to delegate to the context identity method in certain circumstances, you can get at this by calling base.GeneratedId(). Obviously some caution is required when overriding GeneratedId() because the onus is on you to ensure uniqueness. E.g. copying GUID IDs from the local store to the central store is safe, but you wouldn't want to do that with integer IDs. I think this may address your scenario -- let us know. |
|
|
|
|
Thanks I think this may do it. Just the level of hoops I hoped for |
|
|
|
