database support

database support

• awdeoseth

  And very quickly, one can name databases that generally don't see support.  Matisse, for instance.  (I'm not a Matisse user -- I merely mention its omission.)
  
  The point is that (D)Linq is no less agnostic than any other mapper out there.  I would argue that, taken collectively, Linq offers increased levels of agnosticism than any of the proposed alternatives.  In the end, it's just a pattern awaiting implementors.
  
  You mention, and I agree, that *adoption* in the database crowd will depend greatly on how much hand-holding MS offers to transform expression trees into SQL.  Ron should have good comments about this if he's making good progress on his project.
  
  JBoss: Don't get me started.  Really.  The trauma is too fresh.
  
  
  

• benpleysier

  At this point in time we are not planning anything other than SQL Server. Things might change as we move fwd in the project.
  
  The architecture is completely exstensible, so anyone can create his own provider.
  
  

• Phosphorous

  Keith Farmer wrote:

  And very quickly, one can name databases that generally don't see support.  Matisse, for instance.  (I'm not a Matisse user -- I merely mention its omission.)

  Interesting idea.  My subconscious ORM prejudices in action here... hadn't even thought of Dlinq over a database with native OODBMS ability.   

  Keith Farmer wrote:

  The point is that (D)Linq is no less agnostic than any other mapper out there.  I would argue that, taken collectively, Linq offers increased levels of agnosticism than any of the proposed alternatives.  In the end, it's just a pattern awaiting implementors.

  Indeed.  The benefits of compiler-supported query language and expression trees are something that any ORM maker could take advantage of.  Would be much nicer than NH's HQL.  I’d love to QL syntax checked by the compiler rather than by integration tests.

  But, doing ORM with LINQ is much more than just query expressions.  LINQ might provide a unified object query language for ORM in .NET (one day), but the API’s for the various persistence frameworks that might make use of LINQ will remain quite different.  I wouldn’t really expect too many NH users to adopt the Dlinq API as it stands.

  How much knowledge reuse and agnosticism can realistically be expected except for the query expressions   How much real value is there in an agnostic query expression language when the bulk of the ORM adoption effort is in grasping the framework, the mapping vocabulary, the use of the API, and the implicit application micro-architectures driven by the ORM framework

  I agree that LINQ offers increased levels of agnosticism, but I see it as agnosticism in areas that are negligible such that the agnosticism brought by LINQ doesn’t offer too much when applied to ORM.

  Keith Farmer wrote:

  You mention, and I agree, that *adoption* in the database crowd will depend greatly on how much hand-holding MS offers to transform expression trees into SQL.  Ron should have good comments about this if he's making good progress on his project.

  I'm not familiar with the project.  What's it about

  Keith Farmer wrote:

  JBoss: Don't get me started.  Really.  The trauma is too fresh.

  Hibernate trauma, or is this a negative experience from the app server

  I can’t think that it’s anything but a good thing that Sergey Koshcheyev is being paid to work full-time now on NHibernate by a company that now backs two wildly-popular and widely-adopted, free ORM projects than for him to continue to lead the project out of pocket.
  
  Do you think that having JBoss' hands in Hibernate and NHibernate will mess things up   I've got very little experience with JBoss, so your insight would be much appreciated.

  
  

• marcexx66

  The problem I think is in deciding who gets to be responsible for determining the correct syntax for whatever database is being targetted.  MS would take on a huge effort in maintaining at least 3 different tree -> SQL translators just to handle SQL Server, Oracle, and MySQL, let alone others.
  
  Other responses have indicated that they're looking at ways to make it easier for people to write providers for other databases.
  
  

• Ujval vayuvegula

  Keith Farmer wrote:

  He's already got simple SQL support for the DLinq side.  He's actually converting IL blocks to Expression Trees through reflection, which is more difficult, but should retain type safety.

  
  We are working in a similar way: We are using Cecil to convert IL blocks to optimized queries that run against indexes of our object database. We call our approach "native queries".
  
  Our object database is open source, you are invited to take a look how we do it. I suggest that you wait until the final release of 5.0 which will be available next monday.
  
  Further up you asked, whether or not LINQ will support other databases and Luca answered that the architecture is open. We will certainly provide a LINQ implementation for db4o also. http://www.db4o.com
  
  

• Bhawnach

  So.... has ado.net vnext come along to settle the matter
  

• lawyer

  Keith Farmer wrote:

  .. where you still have to provide database-specific sql if the store you use doesn't conform to any dialects provided. There is no true agnosticism in databases...

  While there's no true agnosticism in databases, it might also be said that NHibernate provides database-agnostic support for the databases that matter:
  - SQL Server
  - Oracle
  - MySQL
  - Access
  - DB2
  - Sybase
  - Firebird
  - PostgreSQL
  - SQLite

  It’s been a while since I looked, but I believe Paul Wilson’s OR Mapper (a clone of Microsoft’s own, now-defunct ObjectSpaces framework) supports many, if not all of these databases.

  Keith Farmer wrote:

  There's always someone out there wanting support for some obscure store, and the best people generally do is dumb down the communication enough that they often miss chances to use database-specific optimizations.

  Depends on the effort put into implementing the classes that support a given database.  There’s also a limit to how much optimization can be done on simple CRUD statements – especially when the factor driving the need for the optimizations is a poor data model.

  All this makes me wonder about a couple of things…

  At this point I think the jury is still out on how extensible Dlinq will be.  Is Dlinq a framework, or is it a black box object persistence thing for SQL Server

  If it’s harder to create a provider for Dlinq than it is to use than NHibernate, Wilson’s OR Mapper, etc, will the folks who have been awakened to ORM in .NET by Dlinq’s appearance turn to a more mature framework   If so, which are the kinds of developers who would go with another framework, and which would stick with Dlinq   Is it a Mort/Elvis thing

  If Dlinq is ultimately insufficient at RTM as an ORM product (as compared to existing products), those who would turn to a more mature framework will have their expectations set at quite a high level.  High expectations in the user community would put a lot of the right kind of pressure on Microsoft to evolve a solid ORM engine, a rich and literate metadata mapping vocabulary (that – based on the prevailing experience and recommendations of current ORM developers - isn’t fragmented and scattered across an Entity class definition and compiled into the domain library), and a real, no-kidding persistence *framework* that is indeed factored for extensibility to the extent that something like NHibernate is.

  Personally, I wish that more people who are becoming interested in ORM get some practice with something like NHibernate now so that the right kind of pressure can be put on Microsoft right now to build something robust enough to meet current expectations.

  Keith Farmer wrote:

  DLinq is just an example.  A complex example to implement, but an example nonetheless.

  True dat.  At this early stage, it looks like the path that Dlinq is taking lines it up as more of a reference implementation of how one could use expression trees to build an ORM framework.  But the night is still young, and there’s a non-trivial amount of experience in the folks building Dlinq.  It might be pre-mature to judge the framework now when it’s got all the time between now and Orcas to mature.  It does kinda seem that Dlinq isn’t targeted at mature ORM developers and is trying to be approachable even to the lowliest of developer personas.  It would be unfortunate if the framework was ONLY approachable to newbie ORM developers.

  I personally hope that Dlinq evolves to become as rich as NHibernate and isn’t just some sort of better typed DataSet with cascading operations and lazy loading that avoids using dynamic proxies.  Or, that NHibernate evolves toward making use of LINQ as its query expression language.  Either of these two would make me pleased as punch, but they’ve both got a long way to go.  I want to use Dlinq, I just hope that I don't have to take a step down to do so.

  It’s gonna be really interesting to watch Microsoft and JBoss compete for the hearts and minds of ORM in .NET.  Microsoft has rarely lost these kinds of battles in the past, and its shear size and influence over the community is probably going to be the deciding factor again.  Either way, the tussle oughta be good for ORM in general, and it oughta make for a good show :)  With Microsoft, JBoss, and BEA all getting into ORM within a short window, it might seem to say that ORM may become a competitive hotpoint.  That’s gotta be good.

  Yep… ranting on a tangent again…  Nonetheless, database-agnosticism is quite good right now, here, today, with .NET – and without having to do much more than set a configuration item to indicate which dialect and driver to use.  If screaming, blazing database optimization and eBay-like scale is your concern, ORM probably isn’t the right solution anyway.

  There’s a sweet spot where ORM is applicable.  Generally, it’s broadly applicable.  The cases where tweaks to dialect and driver (provider) classes are needed are often (though not always) cases where a developer chose to use ORM where ORM was a poor choice (ie: Ted Neward’s ORM/Vietnam analogy).  ORM isn’t for everything, and where it’s not applicable, ADO .NET is right there.  And where ADO .NET isn’t applicable, there’s yet a lower layer delivering even better perf.  Achieving screaming, blazing perf and mega scale means using lower-level API’s.  ORM can be a square peg just as easily as it can be a perfect, dreamy solution.

  It’s true that not all ORM provider classes use the most optimized SQL code at their first release.  I guess that’s just another good justification for open source ORM ;)
  

  
  

• schiluveru

  JBoss:
  
  I spent a little over a year having to wrestle with J2EE and JBoss, cobbling together a distributed build system out of what was originally a custom voice messaging system for cellular networks.  I was indifferent to either before I started.  Now I just curl up into a fetal position.  .NET really has spoiled me, and I think that's a Good Thing.
  
  By comparison, just *some* of the classes were 60 pages, printed.  This was before I had to make their workflows run backward.  In Whidbey, they were less than half a dozen, including plenty of whitespace.  They were also a helluva lot more stable.  But, of course, politics being what they are, I had to go to that dark place I try not to think about, and duke it out with Duke and his hordes of Penguinoid Death Eaters (tm).
  
  Linq:
  
  As an undergraduate physics major, many moons ago, I endured a couple years of rather monstrous integrals and differential equations.  Then, one day, they took the entire hydra o' doom and condensed it into nice, simple operator math.  Then they started applying the operators to each other, to show how the composition of the operators remained simple.  In 45 minutes, the entire way to view physics was changed, and became (relatively speaking) comprehensible.  I see DLinq's expression-to-query method being able to do that for data stores.  Sure, there's a lot of hideous stuff happenning in the background, but you don't have to deal with it any more, provided someone does the calculus for you ahead of time.  The big-name vendors certainly will (they have the resources and the motivation).  I would expect to see someone making a least-common-denominator version for ODBC.
  
  Some of the value will come when people start expressing their queries in the programming languages of their choice.  Sure, they have a little syntax to learn, but that syntax doesn't vary with the choice of database since the problem's been turned into third parties providing what are effectively auxillary compilers for the system.  If someone new comes along with a different database with a unique query language, you don't have to spend the time to learn it (unless you're doing something funky).  If you've never dealt with SQL before, you don't have to even start -- you use the same syntax you were using to search object collections.
  
  And then there's the goodness of being able to have composition of queries, and delayed projection:
  
  

  using System; using System.Collections.Generic; using System.Text; using System.Query; using System.Xml.XLinq; using System.Data.DLinq; namespace LINQConsoleApplication1 {  class Program  {   static void Main(string[] args)   {    List<IEnumerable<string>> querySources = new List<IEnumerable<string>>();        querySources.Add(DAL.LongNames);    querySources.Add(DAL.ShortNames);    foreach (IEnumerable<string> querySource in querySources)    {     Console.WriteLine("Query:");     var list =      from q in DAL.NameLengths(querySource)      select String.Format("{0} [{1}]", q.Key, q.Value);     foreach (string s in list)     {      Console.WriteLine(s);     }     Console.WriteLine();    }    Console.ReadKey(true);   }  }  static class DAL  {   public static IEnumerable<string> Names = new string[] { "Alpha", "Beta", "Gamma", "Delta", "Epsilon", "Zeta", "Eta", "Theta" };   public static IEnumerable<string> LongNames   {    get    {     var result =      from n in Names      where n.Length > 4      select n;     return result;    }   }   public static IEnumerable<string> ShortNames   {    get    {     var result =      from n in Names      where n.Length < 5      select n;     return result;    }   }   public static IEnumerable<KeyValuePair<string, int>> NameLengths(IEnumerable<string> query)   {    var result =     from s in query     select new KeyValuePair<string, int>(s, s.Length);    return result;   }  } }

  
  
  

• kemal

  LINQ is actually a C# and VB.NET feature.
  
  DLinq is an extension on ADO.NET that will support at least SQL Server and maybe more, I don't know, I would expect OleDb support, but it is not in the preview. As I understand it the whole mechanisme is extensible so you should be able to write your own providers.

  
  

• Sellerss

  If you want a truely DB agnostic solution consider using the nhibernate OR Mapper instead of LinQ/DLinQ.
  
  

• AlexZander

  Re Ron's project:  He's been making his own implementation of Linq.  He's already got simple SQL support for the DLinq side.  He's actually converting IL blocks to Expression Trees through reflection, which is more difficult, but should retain type safety.
  
  
  

• beerge

  .. where you still have to provide database-specific sql if the store you use doesn't conform to any dialects provided. 
  
  There is no true agnosticism in databases, because there's no true religion regarding backing stores or the query languages used to access them.  There's always someone out there wanting support for some obscure store, and the best people generally do is dumb down the communication enough that they often miss chances to use database-specific optimizations.
  
  With Linq, at least your view of the store remains the same regardless of it being a database, xml file, object collection, generating function, or whatever.  DLinq is just an example.  A complex example to implement, but an example nonetheless.  Following the pattern, you can let it take care of keeping the communication intelligent.
  
  You really need to read beyond the small world of SQL to appreciate what's going on.
  

  
  
  

• David_Croquet

  Actually, I didn't ask -- someone else did.
  
  But I *was* wondering when a Mono-affiliated project was going to be doing something with this, aside from the XLinq classes that were whipped up during PDC.
  
  
• database support