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'm using a few views to project data into a more appropriate form for use in my app. I've created matching entities in Lightspeed Designer and manually created associations from the view entities to the related table entities. However, the designer insists on dropping the associations and recreating the foreign keys as normal entity properties when I execute the "Update from Source" function. Maybe a partial solution to this is to introduce a locking mechanism to the designer, where the user can "lock" (and "unlock" when required) an entity, and the designer will not try and change it during an "Update from Source"... Alternatively, maybe the change determination functionality could be tweaked (not sure what the heuristics would be...) when the entity source is a View... Cheers, |
|
|
Changing the determination behaviour when the source is a view sounds like the ideal solution, but I fear will be a bit tricky to implement. So for the time being I'm afraid you're stuck with the "opt out of synchronisation" solution. And in fact this is already kind of possible: if you change the entity's Access Method to SelectProcedure, it will be excluded from synchronisation. I realise this is misleading to look at but you'll have to judge whether the misleading legend is better or worse than the annoying association behaviour! (Note that the SelectProcedure access method doesn't affect runtime behaviour. However, the StoredProcedures access method *does* affect runtime behaviour. Don't use that unless you really mean it!) |
|
|
Hi Ivan, Thanks for the suggestion. I agree that it would be difficult to determine consistently what is and isn't a valid change when the source is a view. Also, what do you think of the designer locking idea? I suspect this could be useful in other scenarios too. Not sure whether the designer surface would support it, but could it also remove the locked entity from the "Auto-arrange" algorithm? Cheers, |
|
|
Thanks for the suggestions. This is something we're going to have to think carefully about. There are other considerations which tie into this -- we also want to better support databases with limited FK support such as SQLite, which is basically the same scenario as views. So that might point us down the route of doing the extra work anyway -- and I'm wary of adding additional complexity to the sync workflow to work around a problem that we'd rather be solving. (Besides, you just *know* somebody is going to ask for an 'Always tick views when synchronising' option *grin*. And an 'Include locked entities in database sync' one.) Locking is an interesting idea, but I think its semantics would need to be very clear. Excluding from database sync and excluding from auto-arrange are two quite different things after all. |
|