This is possible in theory, but untested :) Pascal. jabber/gtalk: [email protected] msn: [email protected]
On Mon, Mar 9, 2009 at 12:06, Giacomo Tesio <[email protected]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
