On Fri, 2009-03-27 at 09:31 +0100, Giacomo Tesio wrote: > An interessing approach would probably be to create an Ado Provider > able to translate and route the requests created against sqlserver for > the other vendors...
I still fail to see how this would work (or I'm failing to understand what you're saying). > This would work untill in the System.Data.Linq.DataContext code is not > coupled with SQL server interfaces or CLR types (which I cannot know). There's a very simple way to see how tightly coupled DataContext is: pass a non-SQL Server IDbConnection instance to the DataContext constructor. I'll save you time: it throws an exception. You can only pass SQL Server DbConnection types to .NET's DataContext. That's how tightly coupled they are. Consequently, creating a new ADO.NET provider and passing this to DataContext has no chance of working, as (you guessed it) a new ADO.NET provider wouldn't be supported by DataContext. > I know it's a bit like entering from the ass hole (and reparsing the > created SQL to a syntatic tree and back to vendors' sql, but this > could be cached as well), but it would have some advantages. Indeed: http://www.scienceblog.com/cms/brain-surgery-monday-home-tuesday-19809.html But that's not particularly relevant here. > First, on a Microsoft environment, it would be probably easier to get > all the unit test pass on all vendors. > Second, it would probably save almost all of the current DbLinq code, > just adding the new RoutingAdoProvider's classes. So you're proposing writing a new ADO.NET provider which would accept SQL Server string input and would generate SQL commands for another SQL dialect. I believe that this would be nowhere near as easy as you make it out to be, as there can be some fairly substantial differences in SQL dialects. Worst case, it might start looking like machine translation between English and German (which should be easy, right? They're both Germanic languages!). Alas, short of actually attempting the effort I can't say how difficult it would actually be, but it doesn't strike me as a particularly simple solution. (Never mind the fact that using a new ADO.NET provider with .NET's DataContext is impossible...) > Third, it would make the mono's System.Data.Linq.DataContext > development easier: it shouldn't produce the sql server code, just use > directly the SqlProvider of the proper vendor, keeping the duplicated > syntax tree parsing and sql creation only to Microsoft environments. My problem is simple: unused code is buggy code. The fewer developers actively maintaining code, the more likely it is to have unfound bugs. So your approach amounts to punting SQL Server support to me (more or less), and completely dropping it. Instead of (potentially) an entire community of people worrying about SQL Server support, it's...just me. Worst case, SQL server support would get broken during major refactorings of the core, as the code would not be tested as often as the other database providers. For some projects and scenarios, this may make sense. I'm not convinced that this would be helpful here. > Would this way be praticable? No. - 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 -~----------~----~----~----~------~----~------~--~---
