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 love the Update From Source feature. However, there are certain things that I have manually configured in my model that differ from the database, and I need them to stay that way.
Suggestion: Would it be possible in some future version to have the designer REMEMBER exceptions to the rules for later? I'd like to be able to reject a proposed change to my model along with a comment, possibly. From then on the designer would ignore any changes to that property (or the existence) of the field. I suppose this would have to go hand in hand with a mechanism to review and remove the rejections. Kris |
|
|
Hi Kris, Thanks for the feedback. "Don't ask me again about this exception" is definitely something we want to do, but there are a bunch of implementation and usability issues and we just haven't been able to put the work in yet. We do appreciate you letting us know though because customer feedback really helps us prioritise. For your custom type issue, I'm not quite sure what you mean by 'converts to double,' but if you mean you have a custom struct in the CLR model represented as a double in the database, you should be able to get around this by defining a user-defined type with Is Standard Data Type set to True and its Data Type to Double. If that doesn't fit your use case, we'd be interested to hear more details to see if we can improve this for you. I'll try to take a look at the issue of asking to delete columns that are foreign keys but where the referenced table is not represented in the model -- we are a bit busy this week though so I can't make any promises. Chase me up if you don't hear within a week or so! |
|
|
Thanks for the tip on the Standard Data Type thing... It was True but I just hadn't noticed that it was set to a base of Int32! |
|
|
I think I've posted about it before but I think the simplest way to do "exceptions" is just have a checkbox on the sync popup that says "remember exceptions", and then next time you sync the changes you unticked will stay unticked. One thing that I think is important is having exceptions stored in the model file so that other team members working on the same model from source control automatically have changes unticked for them as well. It saves having to tell every team member that when they sync they have to untick the following X changes... |
|
|
Hi James, Yes, the UI isn't the problem -- it's how we store and match exceptions. For example, suppose A excludes an "add column JobStatus to table T" suggestion and we store that as an exception. Now the team takes on a new member, B. B does a sync against his initially blank database, resulting in a bunch of "create table xxx" suggestions. If we just dive in and do the create tables, then table T will get created with all the fields specified in the model, including JobStatus. So we have to figure out that the add column exclusion modifies the 'create table' operation. Multiply this across all the interacting diffs and it could become very complicated, and would require us to significantly rework operations like 'create table.' And what if over time conflicting suggestions build up? (This could easily happen because team members could be tinkering with their private dev databases in different ways as they experiment with different approaches to a model. Even a single dev could build up conflicting exclusions as they muck around with their own database!) 'Remember exclusions' can and should be as simple as you suggest from the user's point of view, but I hope this clarifies why we feel there are significant complexities with implementing it. This isn't to say we're not going to do it -- we have had quite a bit of feedback asking for it and we are listening to the requests -- just might take a bit of time! |
|