License question - MIT vs GPL
PerM
Maybe I've got it all backwards, but how can DbLinq be licensed under
MIT when the MySQL .Net connector (MySql.Data.dll) that ships with
DbLinq is licensed under GPL?
Pascal Craponne
Jens Jacobsen
>> Maybe I've got it all backwards, but how can DbLinq be licensed under
>> MIT when the MySQL .Net connector (MySql.Data.dll) that ships with
>> DbLinq is licensed under GPL?
>>
>> Because DbLinq does not distribute any database vendor.
I'm afraid this is wrong.
Distribution is not a requirement but referencing is. You cannot just
wrap a GPL library in BSD code and then "pretend" it is no longer GPL
unless you have the right to do so.
The following is taken from the GPL FAQ:
<quote>
Can I release a non-free (i.e. anything not GPL) program that's
designed to load a GPL-covered plug-in?
It depends on how the program invokes its plug-ins. For instance,
if the program uses only simple fork and exec to invoke and
communicate with plug-ins, then the plug-ins are separate programs, so
the license of the plug-in makes no requirements about the main
program.
If the program dynamically links plug-ins, and they make function
calls to each other and share data structures, we believe they form a
single program, which must be treated as an extension of both the main
program and the plug-ins. In order to use the GPL-covered plug-ins,
the main program must be released under the GPL or a GPL-compatible
free software license, and that the terms of the GPL must be followed
when the main program is distributed for use with these plug-ins.
If the program dynamically links plug-ins, but the communication
between them is limited to invoking the ‘main’ function of the plug-in
with some options and waiting for it to return, that is a borderline
case.
Using shared memory to communicate with complex data structures is
pretty much equivalent to dynamic linking.
</quote>
Since DbLinq is designed to load Ingres and MySQL data providers and
interact with them, DbLinq is a GPL program and you have the choice to
either:
1. Change the license to GPL
2. Remove MySQL and Ingres from the project. (This is the best
solution in my opinion).
Regards
Jens
Pascal Craponne
Jonathan Pryor
> From the previous discussion:
>
> >> Maybe I've got it all backwards, but how can DbLinq be licensed under
> >> MIT when the MySQL .Net connector (MySql.Data.dll) that ships with
> >> DbLinq is licensed under GPL?
> >>
> >> Because DbLinq does not distribute any database vendor.
>
> I'm afraid this is wrong.
>
> Distribution is not a requirement but referencing is. You cannot just
> wrap a GPL library in BSD code and then "pretend" it is no longer GPL
> unless you have the right to do so.
True, BUT your BSD wrapper code can remain under the BSD license. It's
only when distributed that your BSD code would need to be distributed
under the GPL. The GPL cannot take away copyright, and it cannot stop
me from licensing code under more liberal licenses. It just requires
using GPL-compatible licenses.
Consequently, if someone rewrites that GPL code under BSD, then the
newly written BSD code can be bundled with the old BSD wrapper and
distributed as BSD, not GPL.
...
> Since DbLinq is designed to load Ingres and MySQL data providers and
> interact with them
Stop right there, and consider the ramifications of what you've written
so far. If you have library A which can load library B, and B is
licensed under the GPL, then A must be under a GPL-compatible license.
Yet .NET *itself* is most certainly NOT GPL-compatible (unless you take
the "system-supplied software" route, in which case you can ponder the
equivalent Java case), yet you can load both .NET AND the MySQL data
providers into the same address space (in fact, you must do so unless
you use Mono).
So either:
(1) You can't use the MySQL providers AT ALL (because there's no way for
the entire process to be GPL compatible). This would be quite silly,
but plausibly valid. If this were actually the intention, in order for
ANYONE to use the MySQL providers then they would need to have an
exception in their licensing, e.g. "this code is GPL AND can be used
with .NET." See:
http://www.gnu.org/licenses/gpl-faq.html#LinkingOverControlledInterface
(2) You can use the MySQL providers via standard ADO.NET interfaces w/o
penalty (as .NET would be using the MySQL providers through the standard
interfaces). Though whether this qualifies as the "communication
between them is limited to invoking the ‘main’ function of the plug-in"
case could be debated.
The real problem is that we're dealing with this:
http://www.gnu.org/licenses/gpl-faq.html#GPLPluginsInNF
"Can I apply the GPL when writing a plug-in for a non-free program?"
In this case, the non-free program is .NET itself, while the GPL plugin
is the MySQL provider.
If the program dynamically links plug-ins, and they make
function calls to each other and share data structures, we
believe they form a single program, which must be treated as an
extension of both the main program and the plug-ins. This means
that combination of the GPL-covered plug-in with the non-free
main program would violate the GPL. However, you can resolve
that legal problem by adding an exception to your plug-in's
license, giving permission to link it with the non-free main
program.
As far as my short searching can tell, MySQL provides no such exception,
meaning either (1) you can't ever use it (see above), or (2) you can via
standard interfaces (see above).
Ignoring the .NET angle, for DbLinq there's answer 3:
http://www.mysql.com/about/legal/licensing/foss-exception/
MIT/X11 is listed as a license that gets an exception to the normal GPL
requirements of the MySQL provider. Thus DbLinq is in the clear, full
stop. Have a nice day.
> DbLinq is a GPL program and you have the choice to either:
>
> 1. Change the license to GPL
Again, GPL only covers distribution. It's quite possible, and not
uncommon, to license the source under a more liberal license than the
final binary distribution. All that matters is that at distribution
time you fulfill the GPL, and a more liberal license certainly permits
that.
- Jon
Sami M. Kallio
license, I can use DbLinq and MySQL client in my application? I would not be
able to distribute the MySQL server but my customers could obtain it
themselves.
If it's a gray area, then PostgreSQL might be a wiser choice.
- Sami
Jonathan Pryor
> So in short, if I develop a commercial application, and mention the MIT
> license, I can use DbLinq and MySQL client in my application?
I'm not sure I understand what you mean by "mention the MIT license."
The question is simple: is ALL involved source code available under a
GPL-compatible license (which includes BSD v2, MIT/X11, and a slew of
others)? If it is, you're fine.
Alternatively, if you never distribute your app outside of your company,
you're fine.
If neither of those is true, you _may_ have problems.
> I would not be
> able to distribute the MySQL server but my customers could obtain it
> themselves.
This is also a "workaround" solution as well, and is what allows the use
of binary kernel modules within the Linux kernel -- since the Linux
distro isn't distributing the binary modules themselves, the Linux being
GPL'd doesn't matter (as the "mixed" GPL+proprietary combination is
never distributed and is instead created by the end user).
> If it's a gray area, then PostgreSQL might be a wiser choice.
That said, PostgreSQL would ~always be a wiser choice ;-)
http://sql-info.de/mysql/gotchas.html
I'm not sure I see the point to a DB that permits February 31st as a
valid date...
- Jon
Sami M. Kallio
From: "Jonathan Pryor" <jonp...@vt.edu>
> I'm not sure I understand what you mean by "mention the MIT license."
Poor wording, should have been "by including a copy of the MIT license".
"PostgreSQL has a much simpler licensing scheme. It is released under the
Berkley License, which allows for any use as long as a copy of the Berkley
License is included with it. This means that you can release a commercial
product that uses PostgreSQL or is a derivative of PostgreSQL without
including source code. "
> If neither of those is true, you _may_ have problems.
In this scenario, neither would be true.
> That said, PostgreSQL would ~always be a wiser choice ;-)
Lets say this application would be sold for profit, and it used DbLinq and
PostgreSQL as the backend. By including a copy of the MIT/BSD license from
both, this commercial application would not need to be licensed under GPL,
MIT or any other open source license. Source code could remain closed.
I think that's the safer option, regardless of the merits of the databases,
and the legality of use of MySQL.
- Sami
Jens Jacobsen
removed from DbLinq support, again then fine, but it's probably never
going to happen."
Agreed it is never going to happen. However they will go after the
distributor of your library because any use of DbLinq is effectively
under the GPL (and not the BSD/MIT).
You can license your code any way you want to, as long as you only
distribute source, but there is no way that a programmer can use
DbLinq in unmodified form without being subjected to the GPL, A user
does NOT gain the MIT rights by using DbLinq:
<quote from"http://www.mysql.com/about/legal/licensing/foss-exception/">
Distributors of commercial products that combine GPL-licensed MySQL
software with commercially licensed software (i.e., software not
licensed under a FOSS license) must comply with the terms of the GPL.
This includes use and distribution of the GPL-licensed MySQL database
server and MySQL Client Libraries. The FOSS License Exception does not
apply with respect to products licensed under any license other than
the FOSS licenses listed in the section above titled “FOSS License
List.”
</quote>
the operative quote here is "This includes use" and DbLinq does in
fact use the MySQL client libraries.
The MIT label on DbLinq is more like "false advertising" but not
"legally false" if that makes it more clear.
RE: "Yet .NET *itself* is most certainly NOT GPL-compatible (unless you take
the "system-supplied software" route, in which case you can ponder the
equivalent Java case), yet you can load both .NET AND the MySQL data
providers into the same address space (in fact, you must do so unless
you use Mono)."
First there is the question of who is calling who.
.NET will work perfectly well without the MySQL provider loaded. We
can therefore conclude that the MySQL provider is extending the .NET
base libraries (not the other way around). This is legal because the
.NET standard libraries are "System Libraries" and therefore an
exception to the GPL requirements.
DbLinq is explicitly designed to support MySQL (as a plug in) and
therefore it calls and extends the MySQL provider, therefore DbLinq is
a program designed to load a GPL licensed plug in and hence DbLinq
must therefore in its current form be considered GPL (not MIT).
Second there is the question of who is calling what.
DbLinq is calling interfaces on the MySQL provider that will only work
if it is in fact the MySQL Data Provider that is loaded, this is not
necessarily a problem. You are allowed to do exactly this through the
ODBC interfaces for example without being subjected to the GPL.
However in this case DbLinq is not calling through ODBC but through
loading of a specific GPL licensed component and this means
distribution is not legal without licensing under GPL.
RE: "That said, PostgreSQL would ~always be a wiser choice ;-)"
Except for the few cases where Firebird is the wiser choice, but
generally I agree.
Finally the question of is it legal to redistribute an unmodified
version of DbLinq if your application is not designed to work with
MySQL or Ingres but will in fact only work with Oracle (or something
not GPL).
This is a gray-zone for sure, since it depends on how is the potential
MySQL usage "disabled". Is it through "not tested with" or is the
program actively disabling loading of MySQL and Ingres providers.
The problem as I see it is that if your program "Might" work with
MySQL you must be under the GPL. So again a lot of legal traps is set
up for an unsuspecting programmer, so it is much better to remove the
Ingres and MySQL support in DbLinq mainline and possibly create a fork
that contains everything + MySQL and Ingres (you can call it GPLinq if
you want to :-). This way there is no "false advertising" and
everything is above board.
Regards
Jens
Sami M. Kallio
From: "Jens Jacobsen" <jens.j...@gmail.com>
>
> Finally the question of is it legal to redistribute an unmodified
> version of DbLinq if your application is not designed to work with
> MySQL or Ingres but will in fact only work with Oracle (or something
> not GPL).
If it only works with Oracle, and you only distribute the Oracle portion of
DbLinq, then what? Everything is fine?
DbLinq.dll -> Data -> Linq -> SqlClient, remove other providers and leave
OracleProvider.cs. In you software package, distribute DbLinq. Oracle.dll
and DbLinq.dll, nothing else. Would this do the trick? You might not even
have to remove anything from DbLinq.dll since it doesn't seem to link
against anything GPL but might as well to be safe.
If your software allows 3rd party plugins, licensing issues would be the
problem of the 3rd party. You would not be able to license the plugin as GPL
since the main program isn't, but would it also prevent (legal) in-house
development of such plugin?
- Sami
Jens Jacobsen
to the Ingres and MySQL provider are removed, then you are no longer
touching the GPL.
If you never distribute you app but only use it "in house" then you
are also fine even if you do not modify DbLinq (you can not get in
trouble no matter how much you use GPL code).
BUT........
There are situations where companies has been split up or parts sold
off, suddenly in house developed applications are now distributed and
hence under the GPL distribution requirements again.
So it is not clear cut for any given IT department if DbLinq is ok to
use even in house. The standard rule is "Don't use GPL code in your
development unless you are prepared to distribute your source code"
re: " If your software allows 3rd party plugins, licensing issues
responsible for what 3rd party developers has been doing with their
code.
So unless you step on the toes of Apple or the US Government then you
will probably be ok :-)
re: "You would not be able to license the plugin as GPL since the main
program isn't"
This is from the GPL FAQ right? This explanation is established to
deter sneaky developers from developing applications that has a
proprietary layer but will only work with a GPL licensed plug in. For
example if the DAL layer in your (proprietary) application is
plugable, and one such plug in you provide is a "MySQL plug in"
licensed under the GPL (it might be the only one or it might not) ,
then you have tried to circumvent the GPL according to the FAQ (that
represents the interpretation of the FSF. ie. this is what the FSF
thinks the words in the GPL license means).
re: "but would it also prevent (legal) in-house development of such plugin?"
The GPL only covers distribution of software so this entirely depends
on your in-house rules how "legal" it is. If you have a rule that says
"don't touch the GPL" and you ignore this, you might get fired.
However the company is for sure not doing something illegal in
relation to the GPL as long as they don't distribute, but it might be
illegal in relation to the original software (depending on the EULA
of the original software and other things).
Just to clear a few tings up:
1. If you do not distribute software, you do not need to license your
code at all.
2. Licenses are for distribution.
3. The GPL is one such license that covers distribution of software.
4. According to the FSF FAQ you cannot create an application that is
designed to load a "specific" GPL "Plug in" without licensing the
application itself under the GPL.
5. DbLinq is such an application that is designed to load the GPL
licensed Ingres and MySQL data providers and therefore in its current
form cannot be distributed outside of the GPL.
6. The MySQL license exception is worth nothing because it does not
give you any additional distribution rights that you did not already
have under the GPL, and it does not remove any of the obligations that
you have under the GPL either.
Regards
Jens
Giacomo Tesio
We do not use neither Ingres nor Mysql: we distribute the DbLinq.dll, the DbLinq.SqlServer.dll and the DbLinq.Oracle.dll in our application setups.
AFAIK we have no licencing issue... am I right?
Giacomo
Jonathan Pryor
> RE: "Yet .NET *itself* is most certainly NOT GPL-compatible (unless you take
> the "system-supplied software" route, in which case you can ponder the
> equivalent Java case), yet you can load both .NET AND the MySQL data
> providers into the same address space (in fact, you must do so unless
> you use Mono)."
>
> First there is the question of who is calling who.
> .NET will work perfectly well without the MySQL provider loaded. We
> can therefore conclude that the MySQL provider is extending the .NET
> base libraries (not the other way around).
Yes. But...
.NET provides a way to runtime register ADO.NET providers without
"static" references via Reflection, and exposes a mechanism to do this
via DbProviderFactories.GetFactory() and
DbProviderFactories.GetFactoryClasses():
http://msdn.microsoft.com/en-us/library/h508h681.aspx
http://msdn.microsoft.com/en-us/library/system.data.common.dbproviderfactories.getfactoryclasses.aspx
So IF you have a .exe.config file which registers the MySQL ADO.NET
provider with the runtime (a one line entry in an XML file), then
"magically" System.Data will know about the MySQL ADO.NET provider, and
will return the type when prompted.
This is part of ADO.NET's design, NOT MySQL's.
Thus, the user's code need not directly reference MySQL types *anywhere*
(opting instead to use the System.Data interfaces), and in fact the
provider could be changed dynamically at runtime (simply by asking for a
different provider, the name of which could be stored in a .config
file).
So saying that there's a clear-cut dependency on MySQL is a bit of a
stretch...
> This is legal because the
> .NET standard libraries are "System Libraries" and therefore an
> exception to the GPL requirements.
I don't think so. .NET was not part of the operating system until
Windows Vista, and there are a number of Windows 2000 and XP machines
running around that still don't have .NET installed (which is why
installers for .NET-based programs need to bundle the .NET framework, to
ensure that it gets installed). For Vista and beyond, sure, .NET is
part of the operating system, but I really don't think you can make the
case for older Windows versions.
> DbLinq is explicitly designed to support MySQL (as a plug in)
Eh? It provides glue code to use MySQL SQL dialects, and need not
actually be the "official" MySQL provider. For example, Mono provides
an MIT licensed MySQL provider, which DbLinq could use.
> and therefore it calls and extends the MySQL provider,
I think we have different definitions of "extend." No derivation is
performed on the MySQL provider, no methods are overridden. It does
(indirectly) call the MySQL provider (via System.Data interfaces), but
that's the extent of any such use.
> therefore DbLinq is
> a program designed to load a GPL licensed plug in and hence DbLinq
> must therefore in its current form be considered GPL (not MIT).
It's designed to load any library that implements the System.Data
interfaces. Is it DbLinq's fault that MySQL decided to implement the
standard System.Data interfaces? Does making use of an existing set of
interfaces automagically make it need to conform to the set of licenses
for all potential plugins?
I really don't think so.
Now, if MySQL decided to drop support for the standard interfaces, AND
DbLinq added support for MySQL's proprietary interfaces, then I could
see that "DbLinq is a program designed to load a GPL licensed plug-in."
Barring such stupidity, I really don't see it.
> Second there is the question of who is calling what.
> DbLinq is calling interfaces on the MySQL provider that will only work
> if it is in fact the MySQL Data Provider that is loaded, this is not
> necessarily a problem. You are allowed to do exactly this through the
> ODBC interfaces for example without being subjected to the GPL.
> However in this case DbLinq is not calling through ODBC but through
> loading of a specific GPL licensed component and this means
> distribution is not legal without licensing under GPL.
Er, what?
So actual .NET interfaces should be treated differently from a different
set of interfaces (ODBC), even though they exist to serve the SAME
purpose (DB-independent interaction protocol) and both result in the
loading of GPL-licensed code into your address space?
That makes NO sense to me. Why should ODBC be special in this way?
For example, with this argument you're claiming that the following
program snippet must be licensed under the GPL because it COULD be used
to load MySQL:
class WTF {
public static void Main (string[] args)
{
var connection = (System.Data.IDbConnection)
System.Type.GetType(args [0]);
}
}
How's it load MySQL?
app.exe "MySql.Data.MySqlClient.MySqlConnection, MySql.Data"
This is what you're arguing -- that the above app MUST be GPL'd because
it CAN be used to load a GPL'd ADO.NET provider which conforms to the
STANDARD ADO.NET interfaces.
Granted, DbLinq uses more interfaces than just IDbConnection, but it
still sticks to just the ADO.NET interfaces, and NEVER uses the actual
MySQL types directly (and again, nor does it need to; it could instead
be using Mono's MIT-licensed MySQL driver instead!).
> Finally the question of is it legal to redistribute an unmodified
> version of DbLinq if your application is not designed to work with
> MySQL or Ingres but will in fact only work with Oracle (or something
> not GPL).
> This is a gray-zone for sure, since it depends on how is the potential
> MySQL usage "disabled". Is it through "not tested with" or is the
> program actively disabling loading of MySQL and Ingres providers.
Most people would go the lazy route and just not test it.
Many people also use stored procedures, which would (by definition)
exist only on the database they're using. Would this have any impact on
your analysis? (I'm assuming not, because you could still port those
stored procedures to MySQL, so you could still eventually load the GPL'd
MySQL providers, so you should still be GPL! Crazy.)
> The problem as I see it is that if your program "Might" work with
> MySQL you must be under the GPL.
And this would be bona-fide insane. Believing that Obama can't be
President because he wasn't born on American soil crazy. Again, by this
argument ALL ADO.NET using apps MUST be GPL because they might, some
day, maybe, load the MySQL ADO.NET drivers.
Crazy.
- Jon
Jonathan Pryor
> Just to clear a few tings up:
>
> licensed Ingres and MySQL data providers and therefore in its current
> form cannot be distributed outside of the GPL.
Again, DbLinq is no more "designed" to load the GPL licensed MySQL
provider as .NET *itself* is. DbLinq uses ONLY the standard ADO.NET
interfaces, period.
The only reason DbLinq even has the MySQL provider in svn is to
facilitate unit testing under MySQL. They are not needed unless you're
actually using them (and the only ones using them are people running
DbLinq's unit tests under MySQL....which is no one, at this point).
The only thing that is really questionable is DbLinq.MySql.dll, which
(again) doesn't directly reference MySql.Data.dll. ALL it does is
*generate* SQL in the MySQL dialect, e.g. use '?' for named parameters,
etc. However, MySQL is not the only provider that accepts this dialect;
Mono has an MIT/X11 licensed ByteFX.Data ADO.NET provider which uses the
MySQL SQL dialect. So I don't think you can convincingly argue that
generating SQL for the MySQL SQL dialect counts as "designed to use the
GPL licensed provider."
DbLinq, as currently designed, cannot add any additional GPL violations
over what System.Data already does. Trying to argue otherwise is akin
to arguing that all uses of System.Data require GPL licensing (see other
email for more details).
(And I have never heard anyone before argue that because a GPL'd library
implements an existing 3rd party interface/protocol, all users of that
interface/protocol must also be GPL licensed. It's crazy talk.)
- Jon
Sami M. Kallio
int rowsCount = dbCommand.Command.ExecuteNonQuery();
"INSERT INTO public.session (sessionid) VALUES (nextval('session_sessionid_seq'))" // <- first increment
// the second reads output parameters
SqlStatement "SELECT nextval('session_sessionid_seq')" // <- second increment?
Then commit:
dbCommand.Commit();
The SELECT statement should somehow need to be changed to currval instead of nextval.
- Sami
Sami M. Kallio
> re: "You would not be able to license the plugin as GPL since the main
> program isn't"
>
> This is from the GPL FAQ right? This explanation is established to
> deter sneaky developers from developing applications that has a
> proprietary layer but will only work with a GPL licensed plug in. For
> example if the DAL layer in your (proprietary) application is
> plugable, and one such plug in you provide is a "MySQL plug in"
> licensed under the GPL (it might be the only one or it might not) ,
> then you have tried to circumvent the GPL according to the FAQ (that
> represents the interpretation of the FSF. ie. this is what the FSF
> thinks the words in the GPL license means).
Exactly what I was thinking of. If I distribute an application that uses an
abstract data layer and I provide the interface implementation for the
plugin with say PostgreSQL plugin, but I do not distribute plugins for GPL
licensed databases, there are no license issues. If someone else (a customer
maybe) creates a plugin that interfaces to MySQL, that should not be license
issue for the original program. Could it be licensed under GPL by the
developer or would it be a violation against MySQL's license?
- Sami
Jonathan Pryor
> If I distribute an application that uses an
> abstract data layer and I provide the interface implementation for the
> plugin with say PostgreSQL plugin, but I do not distribute plugins for GPL
> licensed databases, there are no license issues. If someone else (a customer
> maybe) creates a plugin that interfaces to MySQL, that should not be license
> issue for the original program. Could it be licensed under GPL by the
> developer or would it be a violation against MySQL's license?
I'm not sure what "it" refers to in your last sentence. Does "it" refer
to the MySQL-interfacing plugin that someone else wrote? Or to your
app? Either way, I don't think the original app should need to be GPL
licensed.
Plus, it's more "interesting" in .NET. It isn't "I provide an abstract
data layer and then provided an implementation."
Instead, it's:
1. .NET *itself* specifies the relevant interfaces.
2. DbLinq uses *only* the .NET interfaces and types.
2. MySQL *themselves* implemented the .NET interfaces. (As do
PostgreSQL, Oracle, etc., etc.)
So it's not a matter of "I defined an abstract data layer, and someone
else decided to write a wrapper between that layer and GPL'd code," it's
"I wrote to an existing standardized interface, and the GPL developers
themselves wrote an implementation of that standardized interface."
I still don't think this changes anything wrt DbLinq. Claiming that
DbLinq MUST be GPL because it MIGHT load a GPL'd library is crazy.
- Jon
Sami M. Kallio
> to the MySQL-interfacing plugin that someone else wrote?
"It" refers to the plugin.
> Either way, I don't think the original app should need to be GPL
> licensed.
My thought as well. Only if the developer of the original application would
decide to create such a plugin, would there be an issue.
- Sami
Sami M. Kallio
class PgsqlSqlProvider : SqlProvider
{
public override SqlStatement GetInsertIds(IList<SqlStatement> outputParameters, IList<SqlStatement> outputExpressions){
...
ids.Add(outputExpression.Replace("nextval", "currval", true));
...
Andrus
Sami M. Kallio
Federico Di Gregorio
> Anyone successfully using SERIAL? I am having a problem since it seems
> DbLinq code calls the sequence twice, and when it happens, the serial
> gets incremented again. When I insert the first record to a table, the
> serial is set to 1, however the object returned by DbLinq tells me the
> serial is 2. I traced the problem to Upsert in QueryRunner.
> First:
> int rowsCount = dbCommand.Command.ExecuteNonQuery();
>
> "INSERT INTO public.session (sessionid) VALUES
> (nextval('session_sessionid_seq'))" // <- first increment
>
> Next:
> // the second reads output parameters
>
> SqlStatement "SELECT nextval('session_sessionid_seq')" // <-
> second increment?
This is in fact wrong but doesn't happen here when I run the tests. Are
you using the last SVN version?
federico
--
Federico Di Gregorio http://people.initd.org/fog
Debian GNU/Linux Developer f...@debian.org
INIT.D Developer f...@initd.org
Degli altri, della gente senza domande, si puo' fare a meno.
-- macchinavapore
Sami M. Kallio
> you using the last SVN version?
I would think so, I'm opening DbLinq.sln from
http://dblinq2007.googlecode.com/svn/trunk/src
I just did an update to latest version and still getting the same end
result. My sequence looked like this before I ran the code:
-- Sequence: session_sessionid_seq
-- DROP SEQUENCE session_sessionid_seq;
CREATE SEQUENCE session_sessionid_seq
INCREMENT 1
MINVALUE 1
MAXVALUE 9223372036854775807
START 6
CACHE 1;
ALTER TABLE session_sessionid_seq OWNER TO rspass;
I'm getting back 'session_id' of 8, instead of 7, and the SQL statement
(IdQuerySql) is still the same :
{SELECT nextval('session_sessionid_seq')}
What kind of SELECT statement do you get back from
PgsqlSqlProvider.GetInsertIds(...) ?
jaydeep vishwakarma
select last_value from session_sessionid_seq
Sami M. Kallio
Sami M. Kallio
Federico Di Gregorio
> I got it working by hacking the provider:
> class PgsqlSqlProvider : SqlProvider
This was my fault. I introduced the bug while fixing other stuff. Now it
is fixed (in SVN) and I'll see if there is a way to do it using a single
query instead of two (don't think so without changing DbLinq core).
federico
--
Federico Di Gregorio http://people.initd.org/fog
Debian GNU/Linux Developer f...@debian.org
INIT.D Developer f...@initd.org
Gli avvoltoi cinesi si nutrono di arte, ma possono anche mangiare
i `domani'. -- Haruki Murakami
Sami M. Kallio
unless I want to use a released version?
- Sami
Federico Di Gregorio
> Thanks! So the trunk directory is the latest code that I should be using
> unless I want to use a released version?
Yes. Released versions don't even have working PosgreSQL tests. trunk
has the Northwind database and a lot of tests working (but still 144 to
fix :( ).
federico
--
Federico Di Gregorio http://people.initd.org/fog
Debian GNU/Linux Developer f...@debian.org
INIT.D Developer f...@initd.org
Non vi sono certezze, solo opportunità. -- V