Stefan, nice to read this message, you seem to have good practices. My answers: - "protected virtual", no, there is no sense, usually it means that I wrote the class, since I'm the only one doing this. It comes from my experience in refactoring, but it is useless most of the time :) Do what you want for this. - naming conventions, we use .NET naming conventions, as described at http://linq.to/db/DevelopmentGuidelines and it doesn't include the "m" prefix, so we don't use it. Also, I don't like prefixes, it reminds me the old times of MFC (and the hungarian notation, which still makes me hurl). - your conclusions regarding tables, ok, just don't forget to register associations too. - ok for database name - continuous integration would be great, but we require a server with all databases running before doing this. A long time ago I was thinking to distribute (and update) a Linux VM with these, but my linux (as my english :)) sucks, so we're still looking for volunteers.
You contribution is greatly appreciated, thanks. Pascal. On Thu, Oct 16, 2008 at 20:22, Stefan <[EMAIL PROTECTED]>wrote: > > I just started modifying the class already - there are some questions > there: > > Is there any sense in deriving from that class (because currently most > functions are protected virtual)? > > Also about member variables - is there any "standard" way to name them > - since currently they are named in the same style as local variables > and I don't like that a lot - currently I am using mMemberVariable. > > Done some experimenting about the GetTables() function - my > Conclusions (just copied the comment): > > //If the DataContext was a strong typed one (derived with fields for > the tables), > //it returns a list of MetaTables for all this tables. > //But if you call GetTable<T> with an additional table - the table > doesn't get added to this list. > //If you use a vanilla DataContext the list is empty at the beginning > (ok no surprise here), > //if you call GetTable<T> here the table is added to the list. > // > //If you add to properties with the same T of Table<T> only the first > gets into the list. > > > The database name seems to be either the name of the attribute or the > class name, not null if the attribute is not available. > > > And is there something like an Continuous Integration Server for this > Project? > > > > > On Oct 16, 5:38 pm, "Pascal Craponne" <[EMAIL PROTECTED]> wrote: > > Hi Stefan, > > I came to the same conclusion. Our current AttributedMetaModel doesn't > work > > dynamically, and it should (just like linq to sql does). The problem to > be > > solved is that currently, the class reads all tables, then all > associations > > between tables. The idea would be to merge the two steps so we can have a > > method that registers a table, its associations and related tables. > > I was planning to work on it soon, but let me know if you want to fix the > > code by yourself. > > > > Pascal. > > -- > > Pascal. > > > > jabber/gtalk: [EMAIL PROTECTED] > > msn: [EMAIL PROTECTED] > > > -- Pascal. jabber/gtalk: [EMAIL PROTECTED] msn: [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "DbLinq" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/dblinq?hl=en -~----------~----~----~----~------~----~------~--~---
