Hi, glad to read from you again. I'm not sure I get your point, so I explain more mine:1. All vendors are in the System.Data.Linq.csproj. All as internal. 2. The public parts are exactly the same as they are in MS Linq, and we don't care here. 3. The trick is just that we find a way (somehow) to guess the vendor given a IDbConnection or a connection string (I'm more pessimistic about the last one). Where's the mistake above?
On Thu, Sep 25, 2008 at 09:38, Atsushi Eno <[EMAIL PROTECTED]> wrote: > > (sorry for pretty much late reply! I was busy on some other stuff > apart from my job and it somehow dropped from my brain.) > > Pascal Craponne wrote: > > Hi Atsushi Eno, > > > > you are the best politician I've met: if I analyze your text below, here > > what's to be read: > > 1. Pascal is good > > 2. We need him > > 3. It's easier if he doesn't ask for help (even if help can be provided) > > Conclusion: carry on, dude ;) > > Haha. But 3 is not really. I was just afraid that managing contributor > work than hacking is not so lovely for you. I'll ask community for > their interest. > > > Now for the serious part (we are serious people, aren't we): > > I was thinking recently to support other databases than SQL server on > > mono. I read somewhere in MSDN documentation that if no > > ProviderAttribute is specified on the typed DataContext, then the > > database type is guessed by Linq to SQL, based on something like > > internal analysis (a simple query to database?). This way, for example, > > in .NET 3.5 SP1, support for SQL server 2008 has appeared, without > > breaking the specifications. > > An essential problem here is that no matter how we can indicate > provider type through ProviderAttribute, other DatabaseProviders > are implemented based on DbLinq.Vendor.Implementation.SqlProvider > which is not publicly available on MONO_STRICT mode. So it will > stop working when the DBLinq core presumes that SqlProvider is > publicly available (i.e. when the provider is built with non-strict > DBLinq). > > It might work if the public-at-compile-time type became internal > at runtime, but we cannot build other vendor providers, which is > no-go for us. > > > So what if Mono implementation could "guess" the database type, based on > > the connection string or something like this? The implementation would > > either be compliant and support more databases than Linq to SQL. I think > > we could add some internal mechanisms to link to correct database, > > depending on IDbConnection implementation type, for example. > > What do you think of that? > > Yes, that's possible and I thought it should be done inside mono > strict mode DataContext. But the problem above blocks to reach there. > > Atsushi Eno > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
