Is this the end of the world as we know it?

[Pascal Craponne]

Hi everyone,

I write this message as a kind of blog post. Since I have no blog and it relates to DbLinq, the right place to publish seemed to be here.

it's been a long summer, with thoughts and expectations.

VS2008SP1 came out, along with Linq to entities (a.k.a. the ADO.NET entity framework). I've read the documentation, gave it a try, and it appears to be insufficient (at least to me). There is a higher abstraction level, but you need to start from an existing database, leaving all initial modeling useless, and the extensibility isn't that great. Apparently, a lot of people are disappointed by the entity framework (see http://efvote.wufoo.com/forms/ado-net-entity-framework-vote-of-no-confidence/) so let's just forget it for now.

I also took a look back at NHibernate, which is a great product too. Anyway, the linq support is late, and some major performance problems were found.

In fact, I realized this summer that I love Linq to SQL: it is a simple and quite complete product.

I had a chat with George Moudry (DbLinq's owner) and there was the question to freeze the project, since George has other plans, and I was a bit tired of spending my nights on DbLinq.

But I just can't give up. Some projects are still waiting for DbLinq, and we're not far from something usable (for a professional use).

Leaving the project would also be unfair for people like Pablo and the mono team.

Beside this, it is easy to extend, and was sometimes fun to write.

So I'm probably going to code less, and work more as a project manager, if you contributors agree.

So the next steps are:

1. Releasing a version with new engine. This requires some fixes on the "insert" code (Thomas, if you read this, please let me know).

2. Add the missing essential features and get a product close to Linq to SQL.

3. Extend (I have the strong problem of generating only one source file from the dbml, so the code can not be used in a lose coupled n-tier architecture).

4. Support a zillion databases (that's the fun part).

5. Be rich, famous, and let naked girls come to us.

Are you here guys? We've got some work :)

--
Pascal.

jabber/gtalk: pas...@jabber.fr
msn: pas...@craponne.org

[Jiri Moudry]

Pascal, how much effort do you estimate to get the new "sugar" back
end out the door?
I also agree that Linq-to-Sql is a great and simple tool, and still
use the "LinqPreview2006" at my work, where we are stuck on Windows
2000 computers.
And as we discussed, I want to help with two weekends worth of effort.

Looking forward to a new release!

[Pascal Craponne]

We were almost ready to release, but the "insert" feature was broken for two engines (oracle and another).

[Pablo Iñigo Blasco]

Hi guys! nice to hear you again :-)

I think that we aren't far to finish a good product so I hope that we won't need much more work. IMO  most of resting work are little bugs or secondary not implemented features. So that's a good point.

During this summer I have learned a lot about the  new/current engine implementation, IMO my contribution can be useful for this project and I would like that Pascal be more free of work.

Regards my "life-situation", I am working again in my job and also I am studying a postgrade this year. Therefore I will have less time than in summer, of course (that's why I have been away last two weeks among other reasons). Nonetheless I am very motivated with this project so I want to be a key piece and continue working hard to improve it, specially taking care to the relationship with mono.

Regards the current status of the project, I think that there are a couple of complex problems (apart from already commented). I I have tried to solve them without success,  that's why they should be revised by Pascal so I will write a post about this stuff soon as possible (after to test a couple of things, I have forgotten them a bit).

Regards the roadmap, it sounds great, specially 5th point  :-D yeah yeah.. summer parties, naked girls, sun, piña colada with ice an umbrellas...yeah yeah I like your plan  o--(^o^)--o

--
Saludos. Pablo Iñigo Blasco .

[thoma...@googlemail.com]

Hi Pascal,

I was under the impression that I fixed the INSERT problem. Looking at
the test page, it seems, that Ingres is going not particularly bad
(well, you couldn't say very good either).
I've had some minor difficulties with the new engine though but it
might be just due to my stupidness. For instance to do a proper concat
I need some type info from the engine because I might need to do
something like
VARCHAR(num_of_people) || ' People'
and I seem to have no information that the field num_of_people is
integer. But again, I might have overlooked something there.

I should have time to dive into it tonight.

Cheers
Thomas

P.S. Can I post my address here, so that the naked girls know where to
go to?

[Andrus]

My application requires left joins.

So I'm forced to use last pre-Sugar SVN version which supports it. I have made some fixes/enhancements to this to support PostgreSQL properly.

I hope to port them to current SVN if left join becomes available.

 

I have existing database schema so this will not limit EF usage.

However I'm planning to make appliction available in Linux/Mac also, so EF is not an option for me.

 

I tried to use ActiveRecord/NHibernate but DLinq strong typed facilites and language integration seems to be better.

 

So I will continue my attempts to port my application to use DbLinq.

 

Note also that Matt Warren publishes recently sample code in his blog about using other providers with Linq-SQL.

So it may be possible to plug DbLinq provides to Linq-SQL using reflection.

 

Andrus.

[Pascal Craponne]

Hi Thomas, glad to see you alive :)

As far as I remember, there was a problem with Oracle and another vendor (I don't remember which one, but I sent a post on this group at the time).

Apparently, the Insert system doesn't behave well when insert statements are single call statements.

[Pascal Craponne]

Hi Andrus,

If you feel like implementing outer joins in the new engine, that's a benefit for all of us.

contributors are always welcome ;)

[Atsushi Eno]

Hi Pascal,

(It is my personal comment, not as a part of the Mono team.)

> But I just can't give up. Some projects are still waiting for DbLinq,
> and we're not far from something usable (for a professional use).
> Leaving the project would also be unfair for people like Pablo and the
> mono team.

Basically it is up to you whether you stop hacking dblinq or not.
You did a lot of good hacking and we appreciate much for you to have
opened the door to implement System.Data.Linq feature in Mono land.
Nothing is unfair. At least we didn't pay for you ;-)

IF you stopped hacking and the Mono project needs Linq to SQL
functionality within certain timeframe, we will have to assign
ourselves to work on dblinq. (But I rather find it difficult and
will give up to delay our timeframe.) Such work would have happened
no matter whether there was dblinq or not.

Having said that, the above are all for letting you to feel more
free about deciding which to go ;) We'd love you to continue your
dblinq hacking, especially people like Pablo. And there is not
many people who can drive a project that rocks.

We can also ask the mono community widely to help dblinq effort.
Let me know if you want. That may increase your project management
mess though ;)

Atsushi Eno

[Wayne Pedersen]

Hey all -

My name is Wayne - I was introduced to DBLinq via some Googling only about a month ago.  I could not get it to work, but that did not discourage me (I do not think it was producing all the correct code in VB.Net).  I've been developing small client/server apps in VB.Net since 2002 and I see the huge benefit of DBLinq.  I would not want to see this project die or shelved.

LINQ is just too awesome for developers to leave alone, but the only tools available bind one to Microsoft only database world.

I am by no means an expert developer, and I am learning C# on my own.  I would be willing to test and bang on the code, developing minor patches.  I don't want to get in over my head, or make myself out to be an awesome database junkie - I am not.

But, if I can help in some little way - I would like to see this project be able to achive true VS 2008 integration.  I have never helped in an open source project, and I believe the experiance would be a great one, but I will need guidance.

The meek are here to learn and help; are there mentors to guide and teach the meek in this project as well?

Wayne

[Pascal Craponne]

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 ;)

Anyway, thanks.

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.

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?

Pascal.

[Pascal Craponne]

Hi meek Wayne :)

I'm sad to hear that you had problems with DbLinq and VB. DbLinq works (in theory) just like Linq to SQL, so any simple sample code you can find in MSDN should do the trick.

What database do you work with? If it is not Oracle or SQLite (note to Thomas: that's the second non-working vendor), then you can use the latest SVN sources. We currently have problems with insert on Oracle and SQLite, but everything else should work fine.

And if you feel like meekly contributing to DbLinq, you're welcome. We are lacking of VB developpers, and VB generates some strange expressions that sometimes DbLinq doesn't know how to parse.

We have a unit test project in VB.NET working on MySQL, so if you have examples of problems, you can add them there and make required changes in ExpressionLanguageAnalyzer class (which handles all special constructs and translates them to standard ones).

It's up to you. Any contributor is always welcome (even the meek ones ;))

(proud) Pascal.

[Andrus]

 

What do you think of that?

 

 

Not also that in

 

http://blogs.msdn.com/mattwar/archive/2008/05/04/mocks-nix-an-extensible-linq-to-sql-datacontext.aspx

 

Linq-SQL author provides another solution for provider switching which works in Linq-SQL.

 

Andrus.

[Jiri Moudry]

Andrus,
Matt Warren's already published a sample implementation - in 2007 ( 7
article series):
http://blogs.msdn.com/mattwar/archive/2007/07/30/linq-building-an-iqueryable-provider-part-i.aspx
http://blogs.msdn.com/mattwar/archive/2007/07/31/linq-building-an-iqueryable-provider-part-ii.aspx

However, the SQL he generates looks like this:
SELECT * FROM (SELECT * FROM Customers) AS T WHERE (City =
'London')
And as far as I have read, it relies on "Multiple Active Result Sets
(MARS)" and it only runs on SQL server 2005 - it won't run on SQL
Server 2000.
I wonder if Matt's new work is more general?

And Wayne -
Nice to have you interested, please get the source, download NUnit,
and tell us if you have the system running.
If you can step through VB codegen, perhaps you can start fixing it!

[Andrus]

> I wonder if Matt's new work is more general?

Matt's new work is ugly hack.

Andrus.

[Atsushi Eno]

(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 Craponne]

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?

[Atsushi Eno]

Hi Pascal,

Pascal Craponne wrote:
> 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?

Ahh, OK, I was under the impression that other DB vendors than SQL
Server support won't go into System.Data.Linq.csproj (right now
only DBLinq.SqlServer is there). So, it is 1 :)

So, it won't block "identify by connection string" approach once we
get other vendors there. It could be also done for IDbConnection
by identifying its type i.e. "guess vendor by IDbConnection type".
I guess that's easier, especially considering that .ctor(
IDbConnection,...) is already implemented ;-)

Atsushi Eno

[Pascal Craponne]

We finally found a way to include more databases support in System.Data.Linq, that's good news.

I agree with the idea of identifying (probably using fuzzy name recognition) database when giving the IDbConnection.

So, shall we agree on:

1. Adding all vendors to System.Data.Linq.csproj

2. Finding a mecanism to make this fuzzy identification (I don't wan't any reference to any ADO provider in the projects, and I think that this is just not possible for Mono anyway).

Pablo? Do you agree with this too?