Preparing for DbLinq 0.19
Jonathan Pryor
new 0.19 release.
What should 0.19 Include?
========================
The comment came up on IRC previously (in June), and...things have
languished in the meantime. So, what needs to be done for 0.19? My
short list is:
- Fix transaction support.
- Fix DbMetal.
...and that's it. (I had more, but most of them have been fixed in the
meantime, or I find to be less important.)
Transaction support == all Transactions.* tests pass.
DbMetal fixes == I can regenerate the SQLite DB from Northwind.db3
without getting exceptions.
I figure both of those are fixable within the next few weeks.
When should 0.19 be released?
============================
Late November/December would be the time frame.
Anything Missing?
================
As mentioned in numerous places, I don't have access to every database.
Nobody does (afaik). We're also short on developers. Consequently, the
only databases that will be supported are...those that developers on
this list actually care about. :-)
For my part, this includes SQLite and Microsoft SQL Server.
Anything else will be on the "not fully supported" list (to the extent
that anything is "fully support," and looking at the number of
[Explicit] tests, "fully supported" doesn't mean a whole lot anyway).
Thoughts?
Thanks,
- Jon
Thomas Glaser
I used to look after the Ingres plugin until I ran out of spare time
roughly a year ago. I still don't have a huge amount of time but I'll
do my best to get the Ingres support in a somewhat decent shape for
the 0.19 release. Late November/December should be plenty of time for
that.
Cheers
Thomas
Sandro
svn trunk?
Sandro
Sharique uddin Ahmed Farooqui
Sent from my mobile device
Sharique uddin Ahmed Farooqui
(C++/C# Developer, IT Consultant)
http://safknw.blogspot.com/
"Peace" is the Ultimate thing we want.
Jonathan Pryor
plus it adds partial SchemaLoader support for SQL Server (allowing us to
use DbMetal to generate entity definitions from SQL Server).
Transactions are also working (at least, the Insert_Update_Delete.cs
transaction-using samples are now working).
This prompts the immortal question: what's involved in a release?
I see four things:
1. Tag the revision.
2. Build the tree.
3. Create .zip files from the source tree and built binaries.
4. Publish the .zip files on the web site.
Consider this your "last notice." I'll be tagging some time tomorrow,
unless someone has a really good reason to hold off. :-)
Thanks,
- Jon
> --~--~---------~--~----~------------~-------~--~----~
> You received this message because you are subscribed to the Google Groups "DbLinq" group.
> To post to this group, send email to dbl...@googlegroups.com
> To unsubscribe from this group, send email to dblinq+un...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/dblinq?hl=en
> -~----------~----~----~----~------~----~------~--~---
Thomas Glaser
Some of the .DLL's in the lib folder should probably be in the
binary .zip as well. For instance Ingres access won't work without the
actual .NET Data provider Ingres.Stereo.dll.
Currently you've packaged those libs only in the source .zip.
Regards,
Thomas
Jonathan Pryor
> Some of the .DLL's in the lib folder should probably be in the
> binary .zip as well. For instance Ingres access won't work without the
> actual .NET Data provider Ingres.Stereo.dll.
>
> Currently you've packaged those libs only in the source .zip.
Can you elaborate on which ones should be packaged? Additionally, what
the license for those "redistributable" libraries is?
For example, of these files in lib:
* FirebirdSql.Data.FirebirdClient.dll: Presumably the "Firebird
ADO.NET Data Provider" from firebirdsql.org, but what version?
Also, I don't fully understand which license their downloads are
under -- Initial Developers Public License? InterBase Public
License? -- and what restrictions they have. (If it's not BSD,
MIT, or GPL, I don't want to tax my brain reading it.)
* Ingres.Stereo.dll: I can't even find where to download this file
from, so I *really* don't know what license this was released
under. More annoying, if I go to ingres.com and navigate to the
download page for the .NET Data Provider drivers (e.g. [0]), I'm
prompted with a login/password dialog box. Not cool.
* Mono.Data.Sqlite.dll: MIT/X11, but what version? Plus, if
you're using Mono.Data.Sqlite, you're probably using Mono, which
includes Mono.Data.Sqlite *anyway*, so why would we need to
distribute it?
* Mono.Security.dll: A dependency on Npgsql.dll.
* MySql.Data.dll: GPL, leading to a "wonderful" discussion on this
list several months ago [1]. Yes, it should be possible to
distribute GPL'd software with non-GPL'd software "side-by-side"
without causing problems (e.g. a Linux distro), but I don't need
another 30 message long discussion about GPL requirements.
* Npgsql.dll: At least it's MIT/X11, but what version is this?
* nunit.core.dll, nunit.core.interfaces.dll, nunit.framework.dll,
nunit-gui-runner.dll: Needed for unit tests, not actual
assemblies, and thus shouldn't be distributed.
* Oracle.DataAccess.dll: I'm not a lawyer, and don't care to
understand what the restrictions at [2] include. Plus, what
version is this?
* sqlite3.dll: Public domain, but what version?
* System.Data.SQLite.DLL: ditto.
So, for a variety of reasons (questions about versions, licensing
concerns, etc.), DB vendor assemblies should NOT be distributed with
DbLinq. We stick to the standard ADO.NET interfaces for a reason: it
shouldn't matter what ADO.NET provider is used, as long as we can find
it, and we find it through a variety of mechanisms (e.g. via the
connection string's DbLinqProvider and DbLinqConnectionType parameters,
through the DbMetal.exe.config file).
It should be up to the end developer to choose which ADO.NET provider
they want to use (in turn dependent upon the DB they're using), not
DbLinq (unless there's a *really* good reason to do otherwise).
- Jon
Thomas Glaser
I can't help you with the non-Ingres libs and licenses I'm afraid. And
I'm not necessarily a fan of the Ingres login-to-download policy
either...
The Ingres Stereo Provider is a spin off of the original provider and
can be downloaded here:
http://sourceforge.net/projects/ingresstereo/
It is released under GPL.
Regards,
Thomas
> [0]http://esd.ingres.com/product/drivers/.Net_Data_Provider/Windows_32-B...
>
> [1]http://groups.google.com/group/dblinq/browse_frm/thread/9ca9e51b7516a...
>
> [2]http://www.oracle.com/technology/software/htdocs/distlic.html?url=/te...
Andrus
It is reasonable to use latest release from http://npgsql.org :
2.0.7 Released 2009-11-15
> it
> shouldn't matter what ADO.NET provider is used, as long as we can find
> it,
PsqlVendor.cs contains unconditional statement:
SetParameterType(parameter, parameter.GetType().GetProperty("NpgsqlDbType"),
literal);
This works with npgsql data provider only.
Andrus.
Jonathan Pryor
> > it
> > shouldn't matter what ADO.NET provider is used, as long as we can find
> > it,
>
> PsqlVendor.cs contains unconditional statement:
>
> SetParameterType(parameter, parameter.GetType().GetProperty("NpgsqlDbType"),
> literal);
>
> This works with npgsql data provider only.
True in this case, but the other important thing is that it's restricted
to PsqlVendor, and thus that will only be invoked if someone is using a
PostgreSQL "vendor"/SQL dialect. Is there another database that
supports the same SQL dialect as PostgreSQL that isn't PostgreSQL?
(Though the only dialects which have more than one actual implementation
are SQLite (System.Data.SQLite and Mono.Data.Sqlite) and Oracle (ODP.NET
and .NET's provider)...)
That said, we should fix the code to remove this use of NpgsqlDbType.
- Jon
Andrus
> are SQLite (System.Data.SQLite and Mono.Data.Sqlite) and Oracle (ODP.NET
> and .NET's provider)...)
More ADO .NET drivers
http://www.devart.com/dotconnect/
Linq support like in DbLinq:
http://www.devart.com/dotconnect/linq/docs/
Andrus.
Jonathan Pryor
> > (Though the only dialects which have more than one actual implementation
> > are SQLite (System.Data.SQLite and Mono.Data.Sqlite) and Oracle (ODP.NET
> > and .NET's provider)...)
>
> More ADO .NET drivers
>
> http://www.devart.com/dotconnect/
All the more reason to NOT distribute ADO.NET providers within DbLinq's
release ZIP files, AND to remove all provider-specific logic from our
vendor code.
- Jon