Giacomo, adding a new SQL vendor is easy with DbLinq, since most of the work is done by the core. The only still complicated thing is to write a schema extractor. Some refactoring could have been done, and more code pushed to the core, but wasn't done.
Anyway, take a look at a Vendor / SqlProvider implementations, they're fairly simple. Regarding the internal, non extensible Linq to SQL interfaces, things are much different. Everyone thought the choice was political, and today I'm not so sure it is only political. Most of the code is behind IProvider implementation, this means that the SQL vendors would have most of the job to do, thus making the writing of a dedicated driver very long and difficult. Pascal. jabber/gtalk: [email protected] msn: [email protected] On Sat, Mar 28, 2009 at 10:19, Giacomo Tesio <[email protected]> wrote: > > > On Sat, Mar 28, 2009 at 1:36 AM, Jonathan Pryor <[email protected]> wrote: > >> On Fri, 2009-03-27 at 20:50 +0100, Giacomo Tesio wrote: >> >> That said, if the linq datacontext are so hightly coupled with the >> SqlServer ado provider I've no chance to reach this objective as fast as I'd >> hope. >> >> I still don't see how leveraging .NET's DataContext would actually speed >> up Mono support, since Mono support would still need to be written, and >> using .NET's DataContext would not help in any way... >> > > > I think that any big problem can be splitted in simpler ones. > Writing a Linq to Databases is a big "problem", requiring a huge effort. > By splitting (and decoupling) the sql providers to make them work under the > Microsoft DataContext, we would get the sql providers done faster. > Than the Mono DataContext could use them directly. > > The effort required to translate the Microsoft generated SQL to a syntax > tree (in which Skip or Take are correctly translated to the LIMIT and OFFSET > sql concepts) to be back translated against the proper sql provider, would > let us know and undestand better how to write the Mono datacontext. > > More over, suppose DbLinq would be completed faster on a Microsoft > environment ad would become widely used to access, say, Oracle or > PostgreSQL. > Than the Evil M decide to change the DataContext internals: their customers > would have to choose between > 1) switch to SQL Server all their database custers (expensive not only in > term of licence, but also for the switching time required) > 2) switch entirely to Mono (hopefully just recompile their code). > > Finally no internal compatibility would be required: the hacked > datacontext should be used only in the Microsost environment not in > the Mono one, which could directly use the (fastely completed) sql > provider's of the different vendors. > > This is just a split of the problem in smaller one... > (and I understand your fear: the effort required by the Mono environment > would be the greater one, but at least the sql provider code would be > written faster and Mono itself could take advantage from it). > > >> But, the IDbConnection in the constructor interface tell me that, at >> least for their mocking requirements, could have lead the microsoft >> programmers to leave a door open. >> >> Not really. IDbConnection has its uses, but it's inadequate for what >> needs to be done: translating an expression tree into a SQL statement, with >> assistance from vendor-specific code. An additional interface is required. >> >> Apparently such an interface was actually implemented as well; this post >> mentions an IProvider interface: >> >> >> http://blogs.msdn.com/mattwar/archive/2008/05/04/mocks-nix-an-extensible-linq-to-sql-datacontext.aspx >> >> I do not know why it was not made public. >> >> The above post also mentions what's needed in order to mock DataContext, >> which is useful, but to do so requires mucking about in a lot of internal >> data, which is a "compatibility requirement" that I would prefer to not >> worry about. >> > > WOW ! ! ! > > I can guess why such an interface is internal... Microsoft is the Evil, not > its programmers! :-D > > (and thanks for the link it could be useful for other code we will have to > write to, not related with linq!) > > Thanks for this interesting exchange. > I'd really like to find the time to test this way, but actually I've no > time for it. > > If no one think this could be useful, forget it. > > I actually need a working Linq to Database system in a Microsoft > environment. > DbLinq is (quite) such a system. Linq to Sql CLR types' compatibility would > be a plus for our needs. > > That's it. If not possible... nevermind! :-D > > > Giacomo > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
