Next steps for DbLinq

[Pascal Craponne]

Hi everyone,

As you know, the SQL/CLR engine has been changed, so here's the (to be
discussed) roadmap:
1. Preparing the Mono version: we need to prepare the classes in
DbLinq.Data.Linq namespace to match the System.Data.Linq classes.
2. Cleaning up the current implementation: due to new engine, a lot of
classes are now useless.
3. Split the "strict" features (that stick to Microsoft
specifications) and the "extended" features (the ones we wanted to
have anyway, like bulk insert, for example). I wrote a page about this
at http://linq.to/db/SxSVersions
4. Finishing all vendors SQL language implementations (the engine
currently uses a default SQL generator for all vendors, so a lot test
fails because of this). This includes:
4.1: MySQL
4.2: PostgreSQL
4.3: MSSQL
4.4: Oracle
4.5: Ingres
4.6: SQLite (this one should be OK)
5 Finishing the SQL/CLR engine, because some features are not fully
implemented (tricky joins, for example).

All of those points can be parallelized, so I'd like to have
volunteers for each point.
I personnally take the following points:
1.
3.
5.

Pascal.

[amor...@free.fr]

Hello,

Firebird SQL ( http://www.firebirdsql.org ) is not mentioned in point
4.

Is there any plan to implement it ?

See also http://blog.vyvojar.cz/jirka/default.aspx (Coordinator of the
Firebird driver development for the new .NET Entity Framework)

Thanks

Regards

Alexandre

On 15 juin, 12:37, Pascal Craponne <pic...@gmail.com> wrote:
> Hi everyone,
>
> As you know, the SQL/CLR engine has been changed, so here's the (to be
> discussed) roadmap:
> 1. Preparing the Mono version: we need to prepare the classes in
> DbLinq.Data.Linq namespace to match the System.Data.Linq classes.
> 2. Cleaning up the current implementation: due to new engine, a lot of
> classes are now useless.
> 3. Split the "strict" features (that stick to Microsoft
> specifications) and the "extended" features (the ones we wanted to
> have anyway, like bulk insert, for example). I wrote a page about this

> athttp://linq.to/db/SxSVersions

[Pascal Craponne]

Hi Alexandre,

Are you volunteer to do it? A new database support is always welcome :)

Pascal.

[Pablo Iñigo Blasco]

If those are your preferences I would work on:
4.3
4.2
2

However I would like collaborate also with 1, 3, 5 so if you have any task that I could do, please call me.

Regards.

[Pascal Craponne]

OK, you can take point 3.
Point 1 is a bit tricky, since it requires the reuse of current implementation (moving them to new namespace, and making them sticking to standards). We probably need to discuss with Jiri for this point, to see how we could proceed.

--
Pascal Craponne

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

[amoca]

I'm not a C# developer (Delphi mainly) but I can try ;)

I could see how other sql vendors are implemented.

Alexandre

On 15 juin, 13:41, "Pascal Craponne" <pic...@gmail.com> wrote:
> Hi Alexandre,
>
> Are you volunteer to do it? A new database support is always welcome :)
>
> Pascal.
>
>
>

> On Sun, Jun 15, 2008 at 1:25 PM, <amorad...@free.fr> wrote:
>
> > Hello,
>
> > Firebird SQL (http://www.firebirdsql.org) is not mentioned in point

> > 4.
>
> > Is there any plan to implement it ?
>

> > See alsohttp://blog.vyvojar.cz/jirka/default.aspx(Coordinator of the

[F8R]

Firebird support will be sweet, :P.

I'm using it 'bout 2 year, it's Lightweigt and Fast!
I never go back to SQLServer and MySQL again.

(Ok, I was try to install SQLServer Express severall times, just to
try out LINQ, :P)

[Pablo Iñigo Blasco]

I have attached a patch that compiles and works over revision 723. It includes:

· First steps to MONO_STRICT in Test_Nunit_XXX projects
(now all projects ALSO compiles over DbLinq and CLR/System.Data.Linq interface using an original Northwind.dbml and MONO_STRICT simbol)
· Added original Northwind.dbml to MSSQL_Example. It let us to see if test projects compiles refering to System.Data.Linq instead of DbLinq interface

Both changes let us apply test over CLR/System.Data.Linq.dll, (of course only Test_NUnit_MsSql works, but not 100% perhaps some test are wrong)
Some test have had to be wrapped to #if !MONO_STRICT since:
· They have got references to DbLinq.Table or other DbLinq class.
· They use DataContext.GetQueryText method
· They use  NorthwindLocalProperty db = new NorthwindLocalProperty(dbo.DatabaseContext.Connection);

All of these problems will be solved soon in next steps following http://linq.to/db/SxSVersions.

Others:
Nunit libraries updated to 2.2.9 (latest stable version)

Commit? Suggestions? Corrections?

Regards.

--
Saludos. Pablo Iñigo Blasco .

[Pascal Craponne]

Yes, please commit :)

[Pascal Craponne]

Just for information, Jiri is working on point 1: moving classes to
DbLinq.Data.Linq and make them stick to MS linq to SQL specifications.
Since I gave point 3 to Pablo (splitting strict and extended
features), I only keep the point 5 for me, which is a good load
balancing :)

And I just wish to thank everyone on the project for making DbLinq a
very good project.
The code is getting cleaner, we will provide a strict and an extended
version, we will support more and more databases...
It is getting so good that the Mono team is interested in the
project...

Life's good!

On 15 juin, 18:39, "Pascal Craponne" <pic...@gmail.com> wrote:
> Yes, please commit :)
>

> >> On Sun, Jun 15, 2008 at 13:49, Pablo Iñigo Blasco <pibg...@gmail.com>

> >> wrote:
>
> >>> If those are your preferences I would work on:
> >>> 4.3
> >>> 4.2
> >>> 2
>
> >>> However I would like collaborate also with 1, 3, 5 so if you have any
> >>> task that I could do, please call me.
>
> >>> Regards.
>
> >>> On Sun, Jun 15, 2008 at 12:37 PM, Pascal Craponne <pic...@gmail.com>
> >>> wrote:
>
> >>>> Hi everyone,
>
> >>>> As you know, the SQL/CLR engine has been changed, so here's the (to be
> >>>> discussed) roadmap:
> >>>> 1. Preparing the Mono version: we need to prepare the classes in
> >>>> DbLinq.Data.Linq namespace to match the System.Data.Linq classes.
> >>>> 2. Cleaning up the current implementation: due to new engine, a lot of
> >>>> classes are now useless.
> >>>> 3. Split the "strict" features (that stick to Microsoft
> >>>> specifications) and the "extended" features (the ones we wanted to
> >>>> have anyway, like bulk insert, for example). I wrote a page about this

> >>>> athttp://linq.to/db/SxSVersions

[Pablo Iñigo Blasco]

Hi.

On Tue, Jun 17, 2008 at 10:23 PM, Pascal Craponne <pic...@gmail.com> wrote:

Just for information, Jiri is working on point 1: moving classes to
DbLinq.Data.Linq and make them stick to MS linq to SQL specifications.
Since I gave point 3 to Pablo (splitting strict and extended
features), I only keep the point 5 for me, which is a good load
balancing :)

 

I'd like to see your point of view about http://linq.to/db/SxSVersions.
IMHO just a few classes should be visible in System.Data.Linq. I see the following:

DbLinq.Linq.DataContext
DbLinq.Linq.Table<T>
DbLinq.Linq.EntityMRef
DbLinq.Linq.EntityMSet<T>
DbLinq.Linq.ChangeSet

They also should show some members. Partial class seem to solve that problem.
But I have some doubts i.e: What to do with class declaration and interfaces implementation? ie:
That is our Table<T> definition

public class Table<T> :
        IQueryable<T>
        , IOrderedQueryable<T> //this is cheating ... we pretend to be always ordered
        , ITable
        , IMTable
        , IQueryText
        , IQueryProvider //new as of Beta2

However System.Data.Linq should not to implement any interface.

Another case is that we should rename class like EntityMRef and EntityMSet, what do you think about this stuff?

 

And I just wish to thank everyone on the project for making DbLinq a
very good project.
The code is getting cleaner, we will provide a strict and an extended
version, we will support more and more databases...
It is getting so good that the Mono team is interested in the
project...

DbLinq & Mono rules!! ;-D

[Pablo Iñigo Blasco]

Forget this, it was a lapse:

However System.Data.Linq should not to implement any interface.

Anyway,
System.Data.Linq.Table<T> should implement:

IEnumerable
IEnumerable<T>
IListSource
IQueryable
IQueryable<T>
IQueryProvider
ITable

But not
IOrderedQueryable<T>
, IMTable
, IQueryText

how to front this kind of problems?

Regards.

[Pascal Craponne]

I'm supposed to work on unused classes in the next days, so I'll if we can remove those interfaces.

[Atsushi Eno]

Hi,

In MONO_STRICT mode, you do not have to worry about non-public
interfaces. IMTable and IQueryText will become internal in
MONO_STRICT mode, right?

Atsushi Eno

[Pascal Craponne]

I'll see how to remove IQueryText (which is used only once for debug purposes) and the IMTable will become the ITable (provided by the .NET framework)

[pib...@gmail.com]

AFAIK a public class can't implement an interface with less visibility.

what about composition instead of inheritance? perhaps an
internal-proposes wrapper that implements those interfaces?

[Pascal Craponne]

I suggest that you don't worry about this now, I'll examine each interface to see what we need to do and let you know.

[Atsushi Eno]

Not really :)
For example, our remoting MethodCall implements IInternalMessage.
(See mcs/class/corlib/System.Runtime.Remoting.Messaging.)

Atsushi Eno

[pib...@gmail.com]

Anoter point that we sould to have in consideration is how to interact
with vendors in strict mode since they sould not exist in
system.data.linq.

Currenty tey are passed as parameter in datacontext constructor.

Besides vendors projects currently use classes that will be internals
on strict mode.

That is a problem since one of the best features of dblinq is that
lose coupling with vendors.

What do you thing about this stuff?

[pib...@gmail.com]

That sounds great, I am going to tst it :-)

[Pascal Craponne]

My idea was to take advantage of the current implementation.
Today, a vendor implements 3 interfaces:
- IVendor which is the main entry point
- ISchemaLoader, to extract schemas from database (used by DbMetal)
- ISqlProvider, to help generating requests.

All of those interfaces have a default implementation in the core:
- IVendor --> Vendor
- ISchemaLoader --> SchemaLoader
- ISqlProvider --> SqlProvider

So it is easy to make those default implementations stick to a specific database, like SQL Server, and then give the core a default provider.

[Atsushi Eno]

Hello,

Hmm, I noticed that there is some mess on how to do with those
vendor API:

- We cannot expose extra public types in System.Data.Linq.dll.
That means, System.Data.Linq.dll cannot expose interfaces
such as IVendor, ISchemaLoader and ISqlProvider.

- On the other hand, for those vendor implementations they have
to be public somewhere.

- That likely means, they must reside in some different assembly
(unless we use some reflection trick).

- If you are to create different assembly for those interfaces,
you would like to add the default implementations, which likely
depend on existing types in System.Data.Linq.dll (in MONO_STRICT
mode). Since System.Data.Linq.dll needs those vendor API
after all, it likely requires some cyclic builds.

So ... if I am right, we'll need another assembly than
System.Data.Linq.dll anyways.

Atsushi Eno

[pipp...@yahoo.it]

Pascal (or Jiri),

please remember my problem with the "user qualified" tables.

I'm currently on other "urgent" projects and I've been forced to
switch from DbLinq, but I'll be back soon and would like to cooperate.

Thanks,

Dario

> msn: pas...@craponne.org- Nascondi testo citato
>
> - Mostra testo citato

[Pablo Iñigo Blasco]

So ... if I am right, we'll need another assembly than
System.Data.Linq.dll anyways.

I aggree in all of point that you said. However another dll is another kind of incompatibility between mono and MS.Net. A lot of applications would not work due they haven't that new assembly.

IMHO in strict mode we sould sacrifice some features in favour to compatibility with MS.Net.

Context:
*  A great DbLinq feature is that you can implement a new IVendor easily. For using it the only thing that you have to do is to pass the new IVendor implementation as specific domain dataContext's constructor parameter.
* On the other hand System.Data.Linq potentially support a lot implementations of IDbConnection. Theoretically the only thing that you would have to do is to pass the IDbConnection as specific domain dataContext's constructor parameter. In practice MS.NET just support MSSQL.

Proposal:
* Only for strict mode: Make a new csproj, merging with vendors projects and hidding their classes (as internal), we would have just one assembly, in exchange we would lost "new vendors" capabilities.
* We could support a few "standars" IDbConnections (MSSQL,Mysql,Postgre...) and detecting the specific vendor IDbConnection information (even using reflection if it were necesary).

+ System.Data.Linq namespace synchronized between Mono and MS.Net
+ We would support a few vendors (better than ms that just support MSSQL)
- Lost new vendors features for System.Data.Linq (but if you want them you could to use DbLinq directly and the migration wouldn't be hard)

Regards.

[Pascal Craponne]

Hi, complicated dudes.

As probably already explained, we will split the source code files in two categories for each class/interface subject to extensions:
- the MONO_STRICT part, following the strict specifications is in a file (let's say "MyClass.cs")
- the extended part is stored elsewhere (let's say "MyClass.Extended.cs").
If this class implements a strict interface, then we write it in the strict file. This way we can have some other interfaces without problem for
If this class also implements an extended interface, then we declare this in the .Extended.cs file (if we want to keep only a single, we may place all .Extended.cs files into a big #if !MONO_STRICT / #endif).

Regarding the fact of exposing or not an internally required interface when in strict is probably something like:
--------------------------------------------------
#if MONO_STRICT
  internal
#else
  public
#endif
           interface IVendor
--------------------------------------------------

So with this, everybody should be happy :)

And again, let me do some tests before all of this. My objectives include yours, so I'm aware that the MONO_STRICT must not expose anything else than the strict MS specification.

Pascal.

[Pablo Iñigo Blasco]

On Wed, Jun 18, 2008 at 4:47 PM, Pascal Craponne <pic...@gmail.com> wrote:

Hi, complicated dudes.

As probably already explained, we will split the source code files in two categories for each class/interface subject to extensions:
- the MONO_STRICT part, following the strict specifications is in a file (let's say "MyClass.cs")
- the extended part is stored elsewhere (let's say "MyClass.Extended.cs").
If this class implements a strict interface, then we write it in the strict file. This way we can have some other interfaces without problem for
If this class also implements an extended interface, then we declare this in the .Extended.cs file (if we want to keep only a single, we may place all .Extended.cs files into a big #if !MONO_STRICT / #endif).

Regarding the fact of exposing or not an internally required interface when in strict is probably something like:
--------------------------------------------------
#if MONO_STRICT
  internal
#else
  public
#endif
           interface IVendor
--------------------------------------------------

So with this, everybody should be happy :)

Excuse me I thought compiler force to you to put the same interface list in both files. I have tested that... It works like you said. With that solution would be easy to build the DbLinq.csproj (Pascal rules! :-D)

However that does not solve the problem of specific vendors projects. Strict DataContext constructors should not expose a IVendor parameter. Do you disagree with this?

So it is easy to make those default implementations stick to a specific database, like SQL Server, and then give the core a default provider

IMHO it is not the best idea since we only would support one  provider  in strict mode.

Regards.

[Pascal Craponne]

No problem: we can place a strict constructor in the MONO_STRICT file, and place extended constructors in .Extended.cs files.
The default constructor for us would use the default Vendor implementation (the one that's already in the core).

[Pablo Iñigo Blasco]

On Wed, Jun 18, 2008 at 5:25 PM, Pascal Craponne <pic...@gmail.com> wrote:

No problem: we can place a strict constructor in the MONO_STRICT file, and place extended constructors in .Extended.cs files.
The default constructor for us would use the default Vendor implementation (the one that's already in the core).

I understand and it should work fine, but as I have said that solution just let us use one vendor: the default SqlVendor in DbLinq.csproj.
Do you agree with that?

It would be interesting to support (at least) the few vendors that we currently have through the strict constructor (just receiving a specific IDbConnection)

[Pascal Craponne]

Sure, if you simply tell me how Vendors are related to IDbConnections... :)

[Atsushi Eno]

Hello,

Pablo Iñigo Blasco wrote:
> So ... if I am right, we'll need another assembly than
> System.Data.Linq.dll anyways.
>
>
> I aggree in all of point that you said. However another dll is another
> kind of incompatibility between mono and MS.Net. A lot of applications
> would not work due they haven't that new assembly.

That is nonissue. For example our System.Data.dll uses Mono.Data.Tds.dll
which isn't of course used in .NET.

> IMHO in strict mode we sould sacrifice some features in favour to
> compatibility with MS.Net.

If we have different assembly than System.Data.Linq.dll that exposes
those vendor interfaces, it will still assure extensibility.

(Your remaining points are based on the understanding that
sys.data.linq.dll must not depend on anything external. So I skip them.)

Atsushi Eno

[Pablo Iñigo Blasco]

That is nonissue. For example our System.Data.dll uses Mono.Data.Tds.dll
which isn't of course used in .NET.

Ok. You have convinced me.

Nonetheless that supposes that Mono.Data.Tds.dll (or in our case a theoretical DbLinq.Common.dll ) is registered in the GAC.
ie: if I were to use Mono/System.Data.Linq.dll as an external dll in a Ms.Net project I should also to add that theoretical DbLinq.Common.dll. OK I understand that this kind of situations are strange and they don't matter enough, so I your proposal seem the best option for maintaining compatibility.
 

> IMHO in strict mode we sould sacrifice some features in favour to
> compatibility with MS.Net.

If we have different assembly than System.Data.Linq.dll that exposes
those vendor interfaces, it will still assure extensibility.

Another question is: what do you think about IVendor parameter of DataContext constructor?

Thanks to Pascal, you and rest for answering all of these questions, now I see the path to SxSVersion cleaner.

If everybody agrees, I will start extracting dependencies of specific vendors and DbMetal to another project DbLinq.Common.csproj. Dependencies include SchemaLoader and SqlVendor classes...

Regards.

[Atsushi Eno]

Hello,

Pablo Iñigo Blasco wrote:
> That is nonissue. For example our System.Data.dll uses Mono.Data.Tds.dll
> which isn't of course used in .NET.
>
>
> Ok. You have convinced me.
>
> Nonetheless that supposes that Mono.Data.Tds.dll (or in our case a
> theoretical DbLinq.Common.dll ) is registered in the GAC.
> ie: if I were to use Mono/System.Data.Linq.dll as an external dll in a
> Ms.Net project I should also to add that theoretical DbLinq.Common.dll.
> OK I understand that this kind of situations are strange and they don't
> matter enough, so I your proposal seem the best option for maintaining
> compatibility.

Mono's System.Data.Linq.dll must be regarded as totally different
from that assembly from .NET. That is like usual side-by-side
assemblies. So, in theory, there is nothing special that *our*
System.Data.Linq.dll requires DbLinqSomething.dll in the GAC (when
deployed there).

Though I don't think you can add mono's System.Data.Linq.dll without
changes, because it has the same assembly identity as .NET has.
You'll have to rename our assembly after all.

> Another question is: what do you think about IVendor parameter of
> DataContext constructor?

Some DataContext construtcors take MappingSource. In attribute-based
mapping, there is System.Data.Linq.Mapping.ProviderAttribute that
indicates the type of "SqlProvider" as its Type property. (There
should be similar XML syntax for XmlMappingSource.)

Syntactically it allows any kind of type. So we can pass
typeof(FooVendor) there. In DataContext, we can assume that the
type either is derived from SqlProvider or implements IVendor etc.

> Thanks to Pascal, you and rest for answering all of these questions, now
> I see the path to SxSVersion cleaner.

Thanks from me too :)

> If everybody agrees, I will start extracting dependencies of specific
> vendors and DbMetal to another project DbLinq.Common.csproj.
> Dependencies include SchemaLoader and SqlVendor classes...

No problem from my side; it's up to Pascal :-)

Atsushi Eno

[Andrus]

>In attribute-based
>mapping, there is System.Data.Linq.Mapping.ProviderAttribute that
>indicates the type of "SqlProvider" as its Type property. (There
>should be similar XML syntax for XmlMappingSource.)

It would be useful if DbMetal generated entity code can be used with
different databases without changing generated code.

Requiring hard-coded provider attribute for generated DataContext class
prevents this.

Andrus.

[Atsushi Eno]

I understand your concern, though that's what .NET System.Data.Linq
likely does. Also, it could be done as XmlMappingSource.

"How to indicate the default Provider" is a different issue.
In MONO_STRICT land we could indicate it by some custom configuration
section.

Atsushi Eno

[Pascal Craponne]

I don't agree for extracting files to another project. As I said earlier, we will work to avoid this and keep only one project.

[pib...@gmail.com]

In strict mode, where sqlvendor and schema loader classes are
internal, we can't extend them in other projects. do not?

I understood when you said that the default data context constructor
would use the default vendor, but how to use others vendors if?

Of course the most important thing is that everybody agrees on how to
do that. Personally I just want to understand the point of view of
each one.

I understand that is less sexy to have two dlls for dblinq.

Another way could be to have two projects in strict mode and in the
otherwise only one. Cs files would be shared. Like we currently do in
tests projects.

Just an opinion.

Regards.

[Pablo Iñigo Blasco]

#if MONO_STRICT
  internal
#else
  public
#endif

interface nonpublicableClassOrInterfaceInStrictMode

Meanwhile I'll continue working on that. It seem to be an agreement point.

Regards.

[Pablo Iñigo Blasco]

For making that work I have had to fix the current DbLinq.csproj in strict mode, that did not build  in current revision(36 build errors)
I have attached a patch that build also in strict mode.

I have found two kind of errors:

* Needed and not found IQueryText
Solved doing:

#if MONO_STRICT
using System.Data.Linq;
#endif

* DataTable and/or DataContext ambiguous:
Solved doing:

#if MONO_STRICT
using DataLinq = System.Data.Linq;
#else
using DataLinq=DbLinq.Data.Linq.DataContext;
#endif

Of course non-strict mode  also build, and I have passed tests and seem work like before.
And of course in strict mode rest of projects don't build since they reference now internal classes. But DbLinq.csproj build itself.

Now I will follow with the before explained task: make classes internals in DbLinq.csproj

Regards.

[Pablo Iñigo Blasco]

* DataTable and/or DataContext ambiguous:
Solved doing:

#if MONO_STRICT
using DataLinq = System.Data.Linq;
#else

using DataLinq=DbLinq.Data.Linq;
#endif

Excuse me.

[Pablo Iñigo Blasco]

Given the little (or none) acceptance of last patches that I sent, I try it again with new and simpler ones :-)

The following patch take the DbLinq/Data directory and applies the following rule:

Take the following pattern:

namespace DbLinq.Data.Linq.XXX
{
    .....
}
 
Convert it to:

#if MONO_STRICT
namespace System.Data.Linq
#else
namespace DbLinq.Data.Linq
#endif
{
     namespace XXX
     {
           .....
     }
}

Corrections and suggestions are welcome.

This patch work over 754 revision.
Like before the current patch, MONO_STRICT mode does not compile yet.

Regards.

[Pascal Craponne]

I'd rather like a pattern like this:

#if MONO_STRICT
namespace System.Data.Linq.XXX
#else
namespace DbLinq.Data.Linq.XXX
#endif

Just because your pattern confuses ReSharper (and I can't live without it :)). But feel free to commit your patch anyway, we can arrange this later.

Regarding acceptance of you patches, correct me if I'm wrong, but your submissions always get a (motivated) answer. DbLinq is having a difficult time, because a lot of things are changing right now (Mono, strict/extended, new sql engine).
I'm currently working on moving all necessary stuff to *.Data.Linq namespace, after this, the *.Linq namespace should be useless. It takes time, because the insert/update and delete clauses still use the old engine, so I need to switch to new engine (copy/paste/adapt). I expected it to be finished last week-end, but I'm afraid it will require one or two more weeks.
You can already work on pieces already present in *.Data.Linq, since they are close to a "final" version.

[Pablo Iñigo Blasco]

On Mon, Jun 23, 2008 at 6:07 PM, Pascal Craponne <pic...@gmail.com> wrote:

I'd rather like a pattern like this:

#if MONO_STRICT
namespace System.Data.Linq.XXX
#else
namespace DbLinq.Data.Linq.XXX
#endif

That won't we a problem. It only will take a while .
 

Just because your pattern confuses ReSharper (and I can't live without it :)). But feel free to commit your patch anyway, we can arrange this later.

 

 I wouldn't like to commit useless patches so thanks for the suggestion :-)
 

Regarding acceptance of you patches, correct me if I'm wrong, but your submissions always get a (motivated) answer. DbLinq is having a difficult time, because a lot of things are changing right now (Mono, strict/extended, new sql engine).
I'm currently working on moving all necessary stuff to *.Data.Linq namespace, after this, the *.Linq namespace should be useless. It takes time, because the insert/update and delete clauses still use the old engine, so I need to switch to new engine (copy/paste/adapt). I expected it to be finished last week-end, but I'm afraid it will require one or two more weeks.
You can already work on pieces already present in *.Data.Linq, since they are close to a "final" version.

I am aware DbLinq is having a difficult time in the project and to coordinate all of efforts isn't easy. I am sure that you are very busy (and you want to do lot of things in this project) so everybody thanks your work. Needless to say I am here for helping to more experimented members of dblinq in what they need :-)

I have a suggestion, we should spend more time in improving the SxSVersion specification.  Maybe http://linq.to/db/SxSVersions is a bit obsolete and little. I know that it's boring but it's a good point to work in group pararelly. I have heard a lot of opinion about how to get the strict mode, but even now there are some points that aren't clear, at least for me (like how to use other vendors in strict mode)

After doing a couple tasks (namespaces and ITables stuff) I'll send to you a mail with my point of how to implement the strict mode pararelly to your work in a non intrusive way (even if either the new engine isn't  ended or there are a lot of obsolete classes). Of course not for imposing that way, just for share opinions with rest of members and maybe you agree with anything (or not :-))

Regards.

[Pascal Craponne]

Sure, the SxSVersion was a really first draft, I didn't dig at all into possible problems, so you are welcome to spot the missing points and submit solutions (this can even be done directly on the wiki).

[Atsushi Eno]

I was kind of waiting for your SxSVersion work so I haven't posted
for a while (as you wanted us to let you work on your testing).

My current gut feeling is that you cannot really make it to build
System.Data.Linq.dll from DbLinq source just with MONO_STRICT
condition (in terms of vendor extensibility issue) and my wrapper
approach (i.e. write System.Data.Linq.dll as a wrapper to DbLinq)
would be still easier.

If your attempt results in success that's of course great ;-)

Atsushi Eno

> jabber/gtalk: pas...@jabber.fr <mailto:pas...@jabber.fr>
> msn: pas...@craponne.org <mailto:pas...@craponne.org>
>
> >

[Pascal Craponne]

I consider your message a

msn: pas...@craponne.org

[Pascal Craponne]

I consider your message as a challenge :)
(and my hand slipping on keyboard, posting the previous uncomplete post, as a sign of fatigue)

[Pablo Iñigo Blasco]

The wrapper is an option, of course each implementation will have problems, but IMO it is possible and better with MONO_STRICT preprocessor directive.

I throw my roadmap proposal to strict mode.  I have attached a resume file.
Excuse me about the extension, I tried that it were detailed.

===============================================================================================

Prerequisites: we must have different csprojs for strict(System.Data.Linq.csproj) and non strict modes(DbLinq.csproj).

In first place because assembly references, we cannot reference System.Data.Linq in strict mode for evident reasons.
In second place because extensibility. if we want to have public Vendors they mustn't belong to System.Data.Linq project.
In third place because design,  useless files in strict mode, useless files in non strict mode.
In fourth place for suitability: project symbols, builds...
In fifth place because csprojs does not matter in Mono, that won't use DbLinq.csproj but makefiles.

=================================================================================================
First stage: Build a System.Data.Linq with correct public classes.

    1 - In strict mode we should locate all classes into System.Data.Linq.* namespace (even older classes, they likely will disappear in the future)
        - DbLinq.Data.Linq.* would be moved to System.Data.Linq.*
        - DbLinq.* would be moved to System.Data.Linq.Base (this namespace should disappear in the future)
           (as we are currently doing we would use a preprocessor directive for not annoy the non-strict build)

    2 - Some directives will be wrong in strict mode ie: using DbLinq.* (ie: System.Data.Linq.Base.XX won't exist in non strict build) -> apply also using preprocessor directives in that points.
      
    3 - Make all classes visibility internal except the "key classes" (DataContext, DataTable...) also using preprocessor directives

    4 - Add rest of classes of System.Data.Linq to from current mono svn repository (since this project does not references MS/System.Data.Linq.dll). Remove duplicated classes (DataContext, DataTable...)

    5 - Remove some "using System.Data.Linq" since in strict mode we are such namespace
        (we should use a preprocessor directive for not annoy the non-strict build)

    6 - To Add some using directives in strict code ie: System.Data.Base (but they would disappear in the future)


All those task don't annoy the current non-strict build.
Pascal work can continue like nothing happened.

Preprocessor directives explosion is the main threat in this step. But at least they would be located in 3 known places:
    - using blocks
    - namespace declarations
    - classes visibility

At the end of this stage we would have:
    - a non strict mode project that works and builds like now.
    - a strict mode  project builds itself but:
        - It isn't builds in rest of projects of dbLinq (tests, vendors, examples, dbMetal..).
        - Maybe Test_Nunit_Mssql_strict.csproj builds (removing DbLinq.dll and DbLinq.SqlServer.dll reference).
        - And maybe default vendor lets that some those test work fine.

==============================================================================================================================
Second stage: Correct classes interface

In this step we must to avoid preprocessor directives. That could be fatal for the maintainability,
So this step affect to the non strict mode design.

    1 - From those few "key classes" (DataContext, DataTable...) take public members that does not match with .NET interface and do:
            - set them as internal.
            - that change will break the other projects (Tests, Examples, DbMetal) until the point 3.

    2 - Mark those methods with a prefix (ie: "public void foo()" to "internal void strict_foo()")
    3 - Create a extension.cs file with public methods, they only will be stubs. (ie: "public void foo(){strict_foo();}").
        (This file would not be included just in non strict csproj)
    4 - Move constructors that does not match with .net to the extensions file.


Code conventions for Extensions files:
    - Only "key classes" should contain extension files.
    - Extension files methods calls should be forbidden inside neither DbLinq.csproj nor System.Data.Linq.csproj files (you should use the internal ones).
    - Extensions files just define the interface of DbLinq.Data.XXX to outside of the project (DbMetal,Examples,Tests...)
    - They also contains non standard constructors. That constructors shouldn't be used in DbLinq Project.

At the end of this stage we would have:
    - A DbLinq project that works and builds like before but with a few extensions files.
    - A System.Data.Linq.dll that has correct classes and correct methods, but is incompatible with (DbMetal, Examples, Tests..) and does not have Vendors extensibility.


===============================================================================================================================
Third stage: Vendors in strict mode

    1 - Create a new csproj Vendors.csproj with needed classes and interfaces to vendors projects.

    2 - Create code for managing ProviderAttribute for vendors extensibility. Maybe this code will be useful in both System.Data.Linq.csproj and DbLinq.csproj

    3 - How will it affect to DbLinq.csproj? There are two choices:
        A - DbLinq.csproj keep vendors classes.
                 + only one assembly for DbLinq.csproj, everything work like before
                  - DbMetal, Vendors projects won't build with System.Data.Linq.dll but it can be solved duplicating each csproj of the solution and referencing our System.Data.Linq.csproj and Vendors.csproj

        B - DbLinq.csproj lose vendor classes (like System.Data.Linq.csproj)
                - two assemblies referenced in all projects.
                + no csproj explosion.


At the end of this stage everything should work correctly with System.Data.Linq.csproj and DbLinq.csproj.

[Pablo Iñigo Blasco]

To get first stage is not hard. Following the instructions I have a System.Data.Linq.dll whose source code is fully compatible with DbLinq.dll.

Take a look if you want. In the System.Data.Linq assembly does not exsist any namespace called DbLinq.
With this just I want to say that the given roadmap is feasible.

PS: using blocks are a bit dirty because I have used individuals find&replace (regular expressions) in VS.

[Pablo Iñigo Blasco]

Given patch is just for demonstrative proposes and it hasn't completed my roadmap first stage yet.
As I have said using blocks should be cleaner (only one #if #else #endif in each file).
The patch also contains a lot of public classes yet that shouldn't be visible in System.Data.Linq.dll. But that work seem easy, doesn't it?

Of course the given roadmap is just a proposal, just for sharing my point of view.

Regards.

[Atsushi Eno]

Hi,

Pablo Iñigo Blasco wrote:
> The wrapper is an option, of course each implementation will have
> problems, but IMO it is possible and better with MONO_STRICT
> preprocessor directive.

Just curious, what's the disadvantage of wrapper approach? (there
should be some, as you think it worse.)
Since DBLinq fills missing pieces in itself and the API mismatch
issue should go anyways, the only disadvantage was that it requires
another assembly (S.D.Linq.dll itself), which actually apply to
other approaches too.

Atsushi Eno

[Pascal Craponne]

Hi Pablo,

nice roadmap! I've placed it to http://linq.to/SxSRoadmap (and when I find how to add a toggle comments button on wiki master page, I will place my comments there too).
So here are a few comments about your points:
1.1. Moving all *.Linq classes to *.Data.Linq is a bad thing to me, since I will lose track of what's done (*.Data.Linq) and what remains to be done (*.Linq). When I'm finished moving all needed classes to *.Data.Linq, all *.Linq classes will be obsolete and can easily be removed.
1.3. In theory, all *.Data.Linq.* classes should be internal, except of course the strict ones. This means that all Sugar classes should always be internal, for example. As of today, there is no need to make them public.
2.* very smart move :)
3. I'm not sure I understand: could you give me a few more details about each solution?

Regarding the two project files, that could be an option, if the two project files are included in the same solution: this way, we will always be sure that both projects always build (because my main concern is to keep both projects alive).

As you have noticed, your suggestions are not always lost :)

Pascal.

[Pascal Craponne]

Writing an adapter (wrapper) requires to work on a stable basis, and at the moment, DbLinq is everything but a stable basis.
An adapter is also useful when the requested interface doesn't exist. In our case, the requested interface exists, and there is even more (with the non-strict extensions). This is the "more" that we want to cut out, and not to transform the existing.
In fact the wrapper is a good stategy when everyone working on DbLinq is dead, and there is no more support on it (that's the usual business case for an adapter)... ;) Until then, we can probably have a more efficient developement strategy by developping things only once (and Pablo is full of energy :)).

To me the DbLinq-Mono association is a win-win case because we work on the same project: if we have two projects (conceptually speaking), which are DbLinq and the DbLinq-wrapper, there's no need to work together, and I think that both teams have to lose with this situation.

On Tue, Jun 24, 2008 at 06:06, Atsushi Eno <ats...@ximian.com> wrote:

[Pablo Iñigo Blasco]

On Tue, Jun 24, 2008 at 6:06 AM, Atsushi Eno <ats...@ximian.com> wrote:

Just curious, what's the disadvantage of wrapper approach? (there
should be some, as you think it worse.)

 
Let me to study in a more detailed way the wrapper way, dual build seems to be easier, but at this moment I can't justify why that approach seems worse for me, a it just intuition. Of course my intuition can fail and it isn't better than yours, so I am opened to the wrapper way too.

[Pablo Iñigo Blasco]

So here are a few comments about your points:
1.1. Moving all *.Linq classes to *.Data.Linq is a bad thing to me, since I will lose track of what's done (*.Data.Linq) and what remains to be done (*.Linq). When I'm finished moving all needed classes to *.Data.Linq, all *.Linq classes will be obsolete and can easily be removed.

You haven't to move anything in the non strict mode, so you can continue your work.  That movements are only for strict mode, and we would move them to System.Data.Linq.Base (equivalent to DbLinq.~(Data)(.*) that is the things that aren't done) so we will know what is done in both modes.

1.3. In theory, all *.Data.Linq.* classes should be internal, except of course the strict ones. This means that all Sugar classes should always be internal, for example. As of today, there is no need to make them public.

2.* very smart move :)

 
That is even better  because it let us remove some preprocessor directives.

3. I'm not sure I understand: could you give me a few more details about each solution?

that is just

that is just to apply in those "key classes"

#if MONO_STRICT
internal
#else
public
#endif

of course is better to put them internal directly if DbLinq has no necessity for showing them to the outside.
 

Regarding the two project files, that could be an option, if the two project files are included in the same solution: this way, we will always be sure that both projects always build (because my main concern is to keep both projects alive).

 

I agree.

As you have noticed, your suggestions are not always lost :)

:-) that is nice. But as I have said,  suggestions and specially corrections are welcome.

[Pascal Craponne]

Simply said: a wrapper will require us to write twice the same code (interfaces). This is probably why you "feel" that it is worse.

[Pascal Craponne]

What is the need for point 1.1? After adapting all contents to *.Data.Linq, all the *.Linq will disappear, so I don't understand why you need System.Data.Linq.Base. What do you plan to move there?

[Pablo Iñigo Blasco]

On Tue, Jun 24, 2008 at 12:22 PM, Pascal Craponne <pic...@gmail.com> wrote:

What is the need for point 1.1? After adapting all contents to *.Data.Linq, all the *.Linq will disappear, 

so I don't understand why you need System.Data.Linq.Base. What do you plan to move there?

mmm that is true. Since that classes will be removed that movement isn't necessary. The real important stuff in first stage would be to hide most of classes with internal visibility.

Perhaps that movement to System.Data.Linq.Base gives more cohesion to strict mode (instead of a kaos of namespaces) but functionally it isn't necessary.

[Jiri Moudry]

ANother option for IVendor: make it internal, and use the "friend
assmblies" hack:

http://msdn.microsoft.com/en-us/library/0tke9fxk(VS.80).aspx

[Pablo Iñigo Blasco]

I like that.

But in this way we should define statically all the vendors that there will be.
So new user vendors won't be able to see IVendor (and rest of necessary interfaces).

We could use this in System.Data.Linq.csproj and not in DbLinq.csproj.

That is fine for me, however I think that new vendors capability is a "requirement" in Mono/System.Data.Linq.dll, doesn't it Atsushi?

[Pascal Craponne]

Right, it just kills the extensibility, so this is not something to be used for vendors.

[Atsushi Eno]

Hey,

This time it is about your proposal. (I had enough time to read it and
some sleep in this jetlagged Boston stay ;)

Comments inline:

They are just stubs. You don't have to take them (and code formatting
difference will annoy you ;-)

I'm mostly interested in this stage: How can the implementors of
IVendor (especial an external implementor) reference internal abstract
(or possibly non-abstract) default Vendor implementation in strict mode?

The adapter type indicated by ProviderAttribute has to be implemented
by each IVendor implementor and hence its API must be exposed somewhere.

(Plus, I'm not sure if my ProviderAttribute solution is okay for
everyone ;-)

Atsushi Eno

[Atsushi Eno]

Hi,

It's almost not about technical issue though ...

Pascal Craponne wrote:
> Writing an adapter (wrapper) requires to work on a stable basis, and at
> the moment, DbLinq is everything but a stable basis.

We can take any snapshot of DBLinq to build the wrapper.

> An adapter is also useful when the requested interface doesn't exist. In
> our case, the requested interface exists, and there is even more (with
> the non-strict extensions). This is the "more" that we want to cut out,
> and not to transform the existing.

It is out of concern anyways, but the fact was that I find difficulty in
how to implement missing stuff in DBLinq (and hence some members were
left not-implemented).

> In fact the wrapper is a good stategy when everyone working on DbLinq is
> dead, and there is no more support on it (that's the usual business case
> for an adapter)... ;) Until then, we can probably have a more efficient
> developement strategy by developping things only once (and Pablo is full
> of energy :)).

The problem is rather about that it is Linq to SQL, not DBLinq, which
is unlikely improved and hence it will block DBLinq growth at some
stage. And the API is out of our control.
When both sides work together at API level, your point is still valid.
But we work together only to *implement* the API. (When contributing
to non-strict mode, there is no *both* sides ;-) that's a different story.)

> To me the DbLinq-Mono association is a win-win case because we work on
> the same project: if we have two projects (conceptually speaking), which
> are DbLinq and the DbLinq-wrapper, there's no need to work together, and
> I think that both teams have to lose with this situation.

Having separate builds does not mean we both lose. It actually rather
brings more flexibility (we could stick to old dblinq build and give
feedback to you guys), which makes me feel it's better. If there
is no one interested in keeping it up to date, then the cooperation
will stop at that stage. It is the nature of projects that we should
not deny ;) and still does not block further improvements from you guys.

Atsushi Eno

> On Tue, Jun 24, 2008 at 06:06, Atsushi Eno <ats...@ximian.com
> <mailto:ats...@ximian.com>> wrote:
>
>
> Hi,
>
> Pablo Iñigo Blasco wrote:
> > The wrapper is an option, of course each implementation will have
> > problems, but IMO it is possible and better with MONO_STRICT
> > preprocessor directive.
>
> Just curious, what's the disadvantage of wrapper approach? (there
> should be some, as you think it worse.)
> Since DBLinq fills missing pieces in itself and the API mismatch
> issue should go anyways, the only disadvantage was that it requires
> another assembly (S.D.Linq.dll itself), which actually apply to
> other approaches too.
>
> Atsushi Eno
>
>
>
>
>
>
> --
> Pascal Craponne
>

[Atsushi Eno]

As I posted to mono-olive, it took just a few hours.
http://groups.google.com/group/mono-olive/browse_thread/thread/1e59e282884375fd
At least it saved a lot of time and I feel it is "easier" (and that's
one of the reason why I find wrapper approach better).

When I was writing it, the most significant problem was impedance
mismatch that is being solved by this SxS effort.

BTW take my opinion as "you don't have to go messy way, there is
likely an easier solution" rather than "you had better discard your
attempt and go along with my proposal" ;-) That's not my intention.

Atsushi Eno

[Jiri Moudry]

Another option is to make IVendor internal, and use the hack of
"friend assemblies" to link to it.
http://msdn.microsoft.com/en-us/library/0tke9fxk(VS.80).aspx

[Atsushi Eno]

Hey,

Extensibility in MONO_STRICT mode is not a "requirement", but at least
I personally love such an extensible implementation much more, and I'm
sure you guys also do too ;-)

But if the only solution is to use InternalVisibleToAttribute, then
I'm fine with it. Actually I see the only possible solution there.

Atsushi Eno

[Pablo Iñigo Blasco]

This email is under supposition that we will continue with the SxSVersion instead the wrapper approach.
 

I'm mostly interested in this stage: How can the implementors of
IVendor (especial an external implementor) reference internal abstract
(or possibly non-abstract) default Vendor implementation in strict mode?

We have a lot of options (Jiri also proposed friend assemblies) but here you are others.

The adapter type indicated by ProviderAttribute has to be implemented
by each IVendor implementor and hence its API must be exposed somewhere.

 

* Add to the solutions a new Vendor.csproj. (that contains the public and necessary classes for implementing a new vendor: IVendor..). Here is where API is exposed.
* System.Data.Linq.csproj doesn't contain those classes(IVendor...).
* System.Data.Linq.csproj references Vendor.csproj

In DbLinq we have two options
A - DbLinq.csproj wich contains IVendor and rest of classes and doesn't reference to Vendor.csproj .
A- Problems: Vendors wouldn't be compatible between System.Data.Linq.csproj and DbLinq.csproj. We would need new csprojs for each vendor. (referencing)

B- DbLinq.csproj also references Vendor.csproj. That would be easier but dblinq would have two main assemblies.

The adapter type indicated by ProviderAttribute has to be implemented
by each IVendor implementor and hence its API must be exposed somewhere.

 (Plus, I'm not sure if my ProviderAttribute solution is okay for

everyone ;-)

It is ok for me. Though I would like to have an attribute in vendor implementation instead of the specific domain DataContext. and use the IDbConnection for choose the specific Vendor. ie:

[UsesConnection(ConnectionType=typeof(MySqlConnection))]
public class myVendor:IVendor
{ ...}


public class DataContext: ..
{
       public DataContext(IDbConnection conn)
       {
             Assembly a=...
             Type vendorType=a.GetTypes().First(t=> t.isAttributedWith<UsesConnection>() && t.GetCustomAttribute<UsesConnection>().ConnectionType==conn.GetType()).GetCustomAttribute<UsesConnection>().ConnectionType;

            Vendor v= Activator.CreateInstance(vendortype... etc) as IVendor;
             .......
       }
}

The only advantage of this approach is to free to the data context user to specify the ProviderAttribute. That could be cool when we don't know at design time the type of conn object.

[Pascal Craponne]

I also like the Provider approach, that we can implement, without losing the fact of specifying explicitly a vendor.
Regarding your option, Pablo, I'm afraid it's not possible because it requires to reference a specific IDbConnection implementation per vendor, and we can not be that restrictive. Currently, vendors do not (and must not) reference at all any database driver, allowing the used to choose its own implementation and version.

[Pablo Iñigo Blasco]

 Currently, vendors do not (and must not) reference at all any database driver, allowing the used to choose its own implementation and version.

I agree. :-)

[Pablo Iñigo Blasco]

> An adapter is also useful when the requested interface doesn't exist. In
> our case, the requested interface exists, and there is even more (with
> the non-strict extensions). This is the "more" that we want to cut out,
> and not to transform the existing.

It is out of concern anyways, but the fact was that I find difficulty in
how to implement missing stuff in DBLinq (and hence some members were
left not-implemented).

Like we have *.Extensions.cs files included exclusively in DbLinq.csproj, we could have other *.Extensions.cs included exclusively in System.Data.Linq.csproj.... Anyhow I agree that the model is getting more and more complex... :-/

The problem is rather about that it is Linq to SQL, not DBLinq, which
is unlikely improved and hence it will block DBLinq growth at some
stage.

if those improvements concern just API I think that it is solved with extensions files. If DbLinq had more functionality that would be great great, we just should hide that methods using the extension file convention (All public members exclusively of DbLinq must be in a Extension.cs file not included in System.Data.Linq.csproj)
 

And the API is out of our control.

As you said, it likely it won't change.

=============================================================

BTW take my opinion as "you don't have to go messy way, there is
likely an easier solution" rather than "you had better discard your
attempt and go along with my proposal" ;-) That's not my intention.

Another option is to do a merge, trying to get best features of each approach.
Here you are another proposal:

- Use the wrapper model but sharing source to avoid cyclic build etc..
- We dont need to rename DbLinq.* namespaces  since we have using wrappers
- We still need strict mode for class visibility. (every DbLinq.* should be internal in strict mode) but not for namespace names.
- DbLinq.csproj would have a reference to gac System.Data.Linq.dll.
- On the other hand System.Data.Linq.csproj contain such namespace itself.

That approach improve (theoretically) code clearness. It also is good for avoiding cyclic build (like SxS best feature) and also let DbLinq project be more free for evolving, changing etc...

We would continue with the Vendors problem. About this problem IMO there is only a good escape: extract vendor common classes to other assembly and reference this assembly from DbLinq.csproj and System.Data.Linq.csproj.

Otherwise vendors wont be reusable between projects using DbLinq and System.Data.Linq since the specific vendors has been built referencing only one of them, I mean two assemblies (System.Data.Linq.dll and DbLinq.dll) implies two families of vendors.

I see that we are a bit blocked, but we must continue with this discussion until we arrive to an agreement.

Regards.

[Pascal Craponne]

I'm not favorable to the wrapper approach, anyway the idea to include vendors code in the forthcoming System.Data.Linq.csproj is a good idea. This, coupled to Provider attribute support may lead to a good API compatibility.

--
Pascal Craponne

jabber/gtalk: pas...@jabber.fr

msn: pas...@craponne.org

[Pablo Iñigo Blasco]

Maybe I haven't expressed it correctly.
 

the idea to include vendors code in the forthcoming System.Data.Linq.csproj

The idea was to extract common vendor classes (IVendors.. etc) to another csproj (ie:Vendors.csproj) and reference this assembly(Vendors.dll)  from System.Data.Linq.csproj and also from DbLinq.csproj

I know, it is ugly to separate those classes in two assemblies, but I think that it is worse than either:
 to lose extensibility ("Including vendors code in the forthcoming System.Data.Linq.csproj") or to have two families of vendors assemblies (using the friend assembly option) (each family referencing one of the choices: DbLinq.dll or System.Data.Linq.dll )

[Atsushi Eno]

Oh, well, OK I thought Vendor csproj somewhat different (something
like vendor-specific stuff). So you guys agreed to my suggestion
to have separate assembly other than *.Data.Linq.dll ("Vendor.dll"
does not sound great though).

Then the approach looks fine to me too :)

Atsushi Eno

[Pascal Craponne]

I'm lost. Why changing DbLinq's organization if there is a new project file for Mono System.Data.Linq?

Regarding DbLinq, we can keep the whole thing as it is:
- a core: DbLinq exposing a public IVendor & friends
- vendors: DbLinq.*

Regarding Mono:
- a unique assembly, with internal IVendor, and internal implementations
- if you want to keep extensibility, we'll be out of MS scope anyway, so we can make the IVendor interface just public.

What's wrong with that?

[Atsushi Eno]

Hi,

Pablo Iñigo Blasco wrote:
> > An adapter is also useful when the requested interface doesn't
> exist. In
> > our case, the requested interface exists, and there is even more
> (with
> > the non-strict extensions). This is the "more" that we want to
> cut out,
> > and not to transform the existing.
>
> It is out of concern anyways, but the fact was that I find difficulty in
> how to implement missing stuff in DBLinq (and hence some members were
> left not-implemented).
>
>
> Like we have *.Extensions.cs files included exclusively in
> DbLinq.csproj, we could have other *.Extensions.cs included exclusively
> in System.Data.Linq.csproj.... Anyhow I agree that the model is getting
> more and more complex... :-/

I misused past tense; the fact was I found it difficulty there. That is
all about past tense talk. As I've already said, dblinq is getting
API compatible with S.D.Linq (thanks to SxSVersion work), so this is
really out of concern.

> The problem is rather about that it is Linq to SQL, not DBLinq, which
> is unlikely improved and hence it will block DBLinq growth at some
> stage.
>
>
> if those improvements concern just API I think that it is solved with
> extensions files. If DbLinq had more functionality that would be great
> great, we just should hide that methods using the extension file
> convention (All public members exclusively of DbLinq must be in a
> Extension.cs file not included in System.Data.Linq.csproj)
>
>
> And the API is out of our control.
>
>
> As you said, it likely it won't change.

Then that means, the original concern that Pascal wrote is not existent.

Let's first finish current attempt to the end (the third stage) to see
if everything works fine. The primary concern wrt wrapper approach
is/was that dblinq has/had couple of API/design incompatibility.
With compatible API, it would just need a couple of hours' hacking.

Atsushi Eno

[Pablo Iñigo Blasco]

On Tue, Jun 24, 2008 at 7:29 PM, Pascal Craponne <pic...@gmail.com> wrote:

I'm lost. Why changing DbLinq's organization if there is a new project file for Mono System.Data.Linq?

Regarding DbLinq, we can keep the whole thing as it is:
- a core: DbLinq exposing a public IVendor & friends
- vendors: DbLinq.*

Regarding Mono:
- a unique assembly, with internal IVendor, and internal implementations
- if you want to keep extensibility, we'll be out of MS scope anyway, so we can make the IVendor interface just public.

What's wrong with that?

That I said was only an idea to saving the extensibility regarding Mono. As you said it is out of MS scope, so if everybody agrees with your solution I am happy.

When I said two families of vendors implementations I refered to use (fiends assembly Jiri's proposal). If your idea is to embedd specific vendors to System.Data.Linq.csproj, of course the problem does not exist since extensibility is killed :-)

[Atsushi Eno]

The second assumption on Mono side is wrong:
- We do not accept API metadata incompatibility
- We do accept feature enhancement in non-metadata-wise extensions.
(e.g. our ASP.NET MembershipProvider support does not depend on
MS SQL server. That's not what .NET precisely does.)

Hence, we cannot keep extensibility in Mono in your opinion.

Atsushi Eno

[Pascal Craponne]

Oooops, my sentence was a bit twisted, but you made the point. No extensibility on Mono, we'll embed all current vendors in the System.Data.Linq, and work with Provider.
Agreed?

msn: pas...@craponne.org

[Pablo Iñigo Blasco]

Resume about vendors approachs:

1. Embed specific vendors implementations to System.Data.Linq.csproj
   + easier
    - not extensible regards mono

2. Extract common vendors public classes from DbLinq to another project(ie: DbLinqCommon.csproj)
   - two core assemblies for DbLinq
  + extensible regards Mono

3. Jiris & Friend assemblies
   - two families of specific vendors implementations
   - really it is not extensible for mono

4. Reflection tricks
  + one family assembly
  + one core assembly for  Mono and dblinq
  - more complex
  - we should minimize methods from common vendors public classes.

[Atsushi Eno]

Oops, looks like it is regarded as pending. Probably everyone including
myself thinks it is not *self who is to determine the direction :)

I'm OK with any approach Pablo would actually take. The final choice
would rather be dependent on whether it is possible or not.

It turned out that Mono people does not really care about losing
extensibility over .NET API, so I, as part of that community, wouldn't
mind much either.

Atsushi Eno