Believe it or not I just came across Linq to Sql about two days ago
and i've really been taken by it so you can imagine my disappointment
when i discovered it only supported Sql Server. I'm aware of ADO.NET
Entity Framework, but at the moment just need something as simple as
L2S which supports at least Sqlite.
Then I found DbLinq which I imagine is awesome and am wondering if
development is active cause I see the last update was about a year
ago; plus are there any other similar actively developed & maintained
open-source projects besides this?
> Then I found DbLinq which I imagine is awesome and am wondering if > development is active cause I see the last update was about a year > ago; plus are there any other similar actively developed & maintained > open-source projects besides this?
Development has effectively stopped, as I've been moved onto other projects (Mono for Android), and I don't know of any equivalents.
I had discussed with the re-linq & re-motion folks about rewriting DbLinq to use re-linq as the intermediate layer, so that we could share DB support, but that was waiting on (1) me getting some free time, and (2) the re-motion folks getting a DB abstraction layer finished so that we could start migrating the DbLinq SQL providers to their model.
On Mon, May 2, 2011 at 6:14 PM, Jonathan Pryor <jonpr...@vt.edu> wrote: > On Apr 30, 2011, at 8:49 AM, hkmshb wrote: > > Then I found DbLinq which I imagine is awesome and am wondering if > > development is active cause I see the last update was about a year > > ago; plus are there any other similar actively developed & maintained > > open-source projects besides this?
> Development has effectively stopped, as I've been moved onto other projects > (Mono for Android), and I don't know of any equivalents.
> I had discussed with the re-linq & re-motion folks about rewriting DbLinq > to use re-linq as the intermediate layer, so that we could share DB support, > but that was waiting on (1) me getting some free time, and (2) the re-motion > folks getting a DB abstraction layer finished so that we could start > migrating the DbLinq SQL providers to their model.
> - Jon
> -- > You received this message because you are subscribed to the Google Groups > "DbLinq" group. > To post to this group, send email to dblinq@googlegroups.com. > To unsubscribe from this group, send email to > dblinq+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/dblinq?hl=en.
> Hi Jon, just a question: does this mean that the mono linq provider is waiting for a deep refactoring?
It means that I have lofty plans that may never see the light of day. :-)
DbLinq could use a major refactoring (see also all the type check code riddled ~everywhere instead of using proper OO abstractions). It could use lots of help in general, frankly (see also the unit tests taking ~10 minutes to execute, _just_ for SQL Server & SQLite). I see re-motion/re-linq as a possible solution to some of this, as they have an existing LINQ abstraction to simplify the writing of IQueryable providers (which can also be used to simplify unit tests -- yay!). What's lacking is a "proper" cross-DB abstraction layer, which is where DbLinq could come in (as DbLinq already supports multiple DBs -- somewhat -- so this would be a good exercise for testing a new cross-DB abstraction).
The problem is that I lack the time to do any of this, and no one else appears to be waiting in the wings to pick things up...
It's a framework to build complex domain driven applications, but it has some problems in common with dblinq: we are designing a query provider and we are going to use re-linq; we need to have multidatabase support (but for example we don't need datamapping for our entities).
This mean that I could help you too, as I did worked on the dblinq code base (up to 0.19 version). From my POV, dblinq used to miss good development documentation: no overall vision and so. I did remember it took days to dive into the code.
What has changed from 0.19? Anyone sketched the architectural vision about the project?
On Wed, May 4, 2011 at 7:16 PM, Jonathan Pryor <jonpr...@vt.edu> wrote: > On May 4, 2011, at 6:08 AM, Giacomo Tesio wrote: > > Hi Jon, just a question: does this mean that the mono linq provider is > waiting for a deep refactoring?
> It means that I have lofty plans that may never see the light of day. :-)
> DbLinq could use a major refactoring (see also all the type check code > riddled ~everywhere instead of using proper OO abstractions). It could use > lots of help in general, frankly (see also the unit tests taking ~10 minutes > to execute, _just_ for SQL Server & SQLite). I see re-motion/re-linq as a > possible solution to some of this, as they have an existing LINQ abstraction > to simplify the writing of IQueryable providers (which can also be used to > simplify unit tests -- yay!). What's lacking is a "proper" cross-DB > abstraction layer, which is where DbLinq could come in (as DbLinq already > supports multiple DBs -- somewhat -- so this would be a good exercise for > testing a new cross-DB abstraction).
> The problem is that I lack the time to do any of this, and no one else > appears to be waiting in the wings to pick things up...
> - Jon
> -- > You received this message because you are subscribed to the Google Groups > "DbLinq" group. > To post to this group, send email to dblinq@googlegroups.com. > To unsubscribe from this group, send email to > dblinq+unsubscribe@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/dblinq?hl=en.
> Acutally I'm currently focused on the Epic.NET project.
> It's a framework to build complex domain driven applications, but it has some problems in common with dblinq: we are designing a query provider and we are going to use re-linq; we need to have multidatabase support (but for example we don't need datamapping for our entities).
And this is why the re-linq folks got in touch with me. Having a "standardized" cross-DB interface to re-linq/etc. would be wonderful. I had suggested following System.Data.Common.CommandTrees for the standardized interface (as that's what EF uses), but (sadly) we found that CommandTrees made all the constructors private/internal. :-(
They also determined that the CommandTrees data structures basically codified/mirrored SQL Server, e.g. (from private email discussing with the re-linq folks):
> E.g., the most efficient way to do paging on MS SQL is to use a > BETWEEN condition where you compare row numbers against page limits. > Because EF does not support this, the command trees also don’t support > this and just use a TOP clausefor the upper bound.
This largely killed my idea of doing much with CommandTrees.
> This mean that I could help you too, as I did worked on the dblinq code base (up to 0.19 version). > From my POV, dblinq used to miss good development documentation: no overall vision and so. > I did remember it took days to dive into the code.
> What has changed from 0.19?
Nothing has changed. :-)
> Anyone sketched the architectural vision about the project?
I've sketched out some ideas in the 0.19 release notes:
Thanks for the replies. Jon I really hope you get together with the re-
linq/re-motion guys to implement the ideas you have, it would be a
shame for a project of this sort to just fade away. Will begin digging
through the existing code base for dblinq and the ideas you've
sketched for 0.19. Never been involved with an open-source project but
I sure hope when the ball gets rolling (again), I get to take part!
Good luck with the Mono for Android project and kudos (old news) for
the 1.0 release.
