Note that there are some explanatory texts on larger screens.

plurals
  1. PODBML customization vs regeneration
    text
    copied!<p>I'm having a database with a lot of foreign key relationships defined. When I simply drag any table involved in these FK connections into the DBML editor, so as to machine-generate the DBML file, these will all be represented as associations.</p> <p>From here I'm able to make any changes to these associations: I might want the parent end of the association to be <code>internal</code> rather than <code>public</code> so that a JSON serializer (say) will not get caught in cyclic references; or in a connection between the tables <code>Form</code> and <code>FormAnswer</code>, I might want the child property to be called <code>Answers</code> rather than the machine generated <code>FormAnswers</code>.</p> <p>Now, if the database design is changed, and I want to update the DBML to reflect this change, it seems these customizations would require me to track down every single change and update it manually (Add property, set it's source, source data type, C# data type...)</p> <p>This can be a rather tedious process; what I'm asking is whether there is any way to automate this.</p> <h2>1. Can I have these changes reflected on the SQL server?</h2> <p>The ideal solution, it seems, would be if there was any way to make these specifications directly in the SQL Server database diagrams, so that a full re-generation of the DBML file (deleting everything and dragging it onto the DBML editor anew) would come up with the exact same result.</p> <p>Suspecting that I would already know about the above, if it was achievable, I'd be happy to settle with:</p> <h2>2. Can I extract these changes to a class of its own?</h2> <p>Since all Linq to SQL entities are being generated as partial classes, I thought for a while that I might be able to create a new file, that I maintain manually, to which I could copy all changes as the ones mentioned.</p> <p>So whenever I've changed an association, I would dig into the designer.cs code, cut the modified association, and paste it into my own file. Upon re-generation, I would expect compiler errors for any duplicates, and easily step through and remove these associations from the DBML. The problem here is that the associations seem to be only properties with attributes. If <code>Form</code> has a property called <code>Answers</code>, and the DBML generator will try to create a property called <code>FormAnswers</code>, the resulting <code>Form</code> object would simply have both properties, which is not at all what I want.</p> <p>Has anybody had any luck with either of these solutions? Or if you know of any other way to deal with the problem, I'm open for suggestions.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload