Another loosely related question: is it possible to move mappings from the attributes to an xml file (afaik using XmlMappingSource, am I right?)?
I've just realized that we need such approach in our code. Attributes based mapping would require changing too much code when moving from a storage to another. Giacomo On Mon, Mar 9, 2009 at 8:11 AM, Pascal Craponne <[email protected]> wrote: > Here, there is a simple answer. > DbLinq (the .NET, extended version), comes as a complement for Linq to SQL. > And it uses as much as possible Linq to SQL types and structures. Type are > only duplicated when we were unable to use the standard types. > > System.Data.Linq (DbLinq strict, for Mono), is Linq to SQL, hence it > defines all required types and structures. > > Pascal. > > jabber/gtalk: [email protected] > msn: [email protected] > > > > > On Mon, Mar 9, 2009 at 02:12, Jonathan Pryor <[email protected]> wrote: > >> On a related subject (of trying to clean up MONO_STRICT), is there any >> particular reason why the RefreshMode enum isn't duplicated into the >> DbLinq.Data.Linq namespace (to parallel System.Data.Linq.RefreshMode)? >> This would make sense to me, given how many other types are (deliberately) >> "duplicated" between the two namespaces. >> >> What brings this up is src/DbLinq/Test/Providers/ReadTests_EntitySet.cs, >> which has the code: >> >> using System.Data.Linq; >> // ... >> #if MONO_STRICT >> using DataLoadOptions = System.Data.Linq.DataLoadOptions; >> #else >> using DataLoadOptions = DbLinq.Data.Linq.DataLoadOptions; >> #endif >> >> I'd like to change this to: >> >> #if MONO_STRICT >> using System.Data.Linq; >> #else >> using DbLinq.Data.Linq; >> #endif >> >> But this causes compilation errors because the same file refers to >> System.Data.Linq.RefreshMode, which no longer exists when MONO_STRICTisn't >> defined. >> >> Does this make sense? >> >> - Jon >> >> >> On Sun, 2009-03-08 at 22:33 +0100, Pascal Craponne wrote: >> >> Your suggestion sounds right (to me). >> >> >> On Sun, Mar 8, 2009 at 22:03, Jonathan Pryor <[email protected]> wrote: >> >> For the Mono testing effort, I would like to use Sqlite with Mono's >> System.Data.Linq.dll, *without *using DbLinq*.dll (as the necessary >> drivers will be built into Mono's System.Data.Linq.dll). >> >> This sounds easy, but is unexpectedly non-trivial because the test code >> uses the MONO_STRICT define to mean two unrelated things: >> >> >> 1. Use the System.Data.Linq namespace instead of the >> DbLinq.Data.Linqnamespace (what I want/need). >> 2. Use the MsNorthwind namespace and not the nwind namespace for the >> generated Northwind database types (e.g. the Customer class, etc.). >> >> >> (2) causes things to fail badly when I try to make things Just Work while >> using Sqlite. >> >> Thus, a question: Why do we have this state of affairs, in which the >> generated Northwind database types are in a different namespace for SQL >> Server vs. everything else? >> >> It would be far cleaner if all generated types were in the same namespace, >> and would allow *removal* of MONO_STRICT from a number of test files that >> just need the Northwind types but not the System.Data.Linq/DbLinq.Data.Linq >> namespace distinction. >> >> The fix is straightforward: Modify >> examples/DbLinq.Mssql.Example/nwind/originalMSNorthwind.designer.cs and >> place the types into the nwind namespace, and update all the test files to >> no longer reference the MsNorthwind namespace. >> >> Is there any reason to not do this? >> >> Thanks, >> - Jon >> >> >> >> >> >> >> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
