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've got a table in my model which is backed by a synonym in the db - actual table is in another db. Doesn't look the sync is checking the db synonyms to see if one exists for that table name. Any chance of getting the model-db sync to recognise this? thanks |
|
|
|
|
Sorry, unlikely to implement this unless a few more people ask for it. (It's non-trivial because it's not as simple as a schema-only select, which the synonym would handle for us -- we need to get at the actual table metadata, which means we would need to resolve the synonym ourselves, connect to the other database, etc.) |
|
|
|
|
ok, but if say, you had metadata on the model which indicated to the designer sync that it could ignore specific errors for a given entity (see http://www.mindscapehq.com/forums/Thread.aspx?ThreadID=4296 !) then would that work? i'm imagining (again) that I could flip a flag in the designer for that entity which might set an attribute... If SyncShouldIgnoreTableExistenceCheckAttribute exists on entity then leave out of model/db sync results. Same idea as SyncShouldIgnorePropertyNullabilityAttribute and SyncShouldIgnoreAssociationNullabilityAttribute |
|
|
|
|
I really don't want to bog the designer down in 'ignore this/ignore that' options (and realistically it would not stop at 'existence' and 'nullability'). I'm amenable to a 'default changes on this entity/property/assocation to unselected' option, but it would apply to *all* changes on that element. (Obviously, you could still select in the changes you did want, e.g. if you changed a data type.) Or I guess I could horribly overengineer the thing with some sort of plug-in/policy model. That's always a safe plan... |
|
|
|
|
ok, yah, that's fair enough for outlying cases like this. i agree that it wouldn't stop at only existence and you'd end up with a steaming pile of model sync tweaking attributes. but (and now i'm talking about that other thread http://www.mindscapehq.com/forums/Thread.aspx?ThreadID=4296) the nullability of STI derived entity associations and properties is a problem that floods the designer sync with incorrect changes. That is a fairly specific but common case for which I would still like to see a solution. please. :) |
|
|
|
