Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-devel / 2011-01

MySQL 5.5 and Connector System

21 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Andrew Brunner

I just installed MySQL 5.5 and realized that the connector is bound to 5.1. I can see why looking at the code - why this is like that :-)

I had a problem with the usage of $ifdefs all over the place in the code.

It would be worth it since there are so many flavors of MySQL to re-structure the MySQL component suite to employ the usage of

 {$if defined(MySQL50) or defined(MYSQL51) or defined(MySQL55) or
defined(FutureVersions)}
   CODE HERE
{$eslif defined(MYSQL41)}
   OTHER CODE HERE.
{$endif}

IMO, presently the MySQL connection implement is getting too big to just add another ifdef ad-hoc. I did set out yesterday to work on this but I really don't have the time to figure out why the build process on v50 connection didin't have $DEFINE mysql50 on a constant from another unit. I edited the make files to include mysql55 etc.

So the questions are
1.) Is the dynamic unit system that MySQL connector uses compatible with $if rather $ifdef ?
2.) What are the important things to change in /packages/mysql and packages/fcl-db/*sql/ other than the obvious unit names for component version?

I had to abandon this attempt due to lack of time for this particular issue, but wanted to point out that I would be willing to implement mysql connectors as they are released. My primary choice of DBMS is MySQL. And I'm planning to stick with it.

Reply by email

Marco van de Voort
to Andrew Brunner

In our previous episode, Andrew Brunner said:

Show quoted text 11 lines
It would be worth it since there are so many flavors of MySQL to re-structure the MySQL component suite to employ the usage of {$if defined(MySQL50) or defined(MYSQL51) or defined(MySQL55) or defined(FutureVersions)} CODE HERE {$eslif defined(MYSQL41)} OTHER CODE HERE. {$endif}

This is not logical, since it is not known if future versions will belong in the same category as 5.0 or 5.1 before they emerge and are thoroughly tested. This is _THE_ problem with mysql.

I had to abandon this attempt due to lack of time for this particular issue, but wanted to point out that I would be willing to implement mysql connectors as they are released. My primary choice of DBMS is MySQL. And I'm planning to stick with it.

If sb wants in in 2.4.4, I urge you to be quick :-)

Reply by email

Unknown author
to LacaK
LacaK wrote 7 lines
> If sb wants in in 2.4.4, I urge you to be quick :-) > Does it mean, that you are preparing release 2.4.4 in short time ? If yes, then I would happy, if also bug http://bugs.freepascal.org/view.php?id=16493 with attached patch will be commited.

I checked the patch and committed the patch in trunk. Please test and report, then we can merge the patch to fixes.

Michael.

Reply by email

LacaK
to Unknown author
I checked the patch and committed the patch in trunk. Please test and report, then we can merge the patch to fixes.

The patch is ok, as tested and reported also here
http://bugs.freepascal.org/view.php?id=18114
(and I also use this patch in my applications)

Please can you also apply this minor code cleanup:

101 uses
102 - dbconst, sysutils, typinfo, dateutils;
102 + dbconst, sysutils, dateutils;
193 - databaseerror('Parameter type
'+getenumname(typeinfo(tfieldtype),ord(P.datatype))+' not supported.');
193 + databaseerrorfmt(SUnsupportedParameter,
[Fieldtypenames[P.DataType], Self]);

Thanks
Laco.

Show quoted text 6 lines
Michael. _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Unknown author
to LacaK
LacaK wrote 18 lines
> > I checked the patch and committed the patch in trunk. Please test and > report, then we can merge the patch to fixes. The patch is ok, as tested and reported also here http://bugs.freepascal.org/view.php?id=18114 (and I also use this patch in my applications) Please can you also apply this minor code cleanup: 101 uses 102 - dbconst, sysutils, typinfo, dateutils; 102 + dbconst, sysutils, dateutils; 193 - databaseerror('Parameter type '+getenumname(typeinfo(tfieldtype),ord(P.datatype))+' not supported.'); 193 + databaseerrorfmt(SUnsupportedParameter, [Fieldtypenames[P.DataType], Self]);

Done. Revision 16776.

Michael.

Reply by email

LacaK
to Unknown author
Done. Revision 16776.

Thak you very much.

Could I ask how/when are bugs/patch reviewed/commited ? Is there any single person(s) who maintains for example fcl-db or any fpc-developer can apply patches ?
Is there any special time when patches are applied or in trunk can be patch applied any time (so if it is applied depends only on free time of developer(s)?) ?
I am asking because some (simple) patches are waiting relative long time. For example:
http://bugs.freepascal.org/view.php?id=15314
http://bugs.freepascal.org/view.php?id=16924 (patch 1)

This is not criticism ;-)
Laco.

Reply by email

Marco van de Voort
to LacaK: Does it mean, that you are preparing release 2.4.4 in short time ? If yes, then I would…

In our previous episode, LacaK said:

> If sb wants in in 2.4.4, I urge you to be quick :-) > Does it mean, that you are preparing release 2.4.4 in short time ?

More that the process begins. It is at least 3 months between branching and release, though the third of a series is usually quick.

I'm hoping to branch in februari, do a release candidate a month later, and release in may.

If yes, then I would happy, if also bug http://bugs.freepascal.org/view.php?id=16493 with attached patch will be commited.

The remark was mainly made because there were some doubts about the stability etc of the trunk restructuring of dynamic loading of libraries in the database drivers. Later changes in mysql, sqlite can depend on these.

I'm currently categorizing remaining commits to merge here:

http://www.stack.nl/~marcov/mergelogs/

the problem commits are, amongst others:

http://www.stack.nl/~marcov/mergelogs/dynlibs.txt

Reply by email

LacaK
to Marco van de Voort

Hi *,
consider following sample program:

var
  b: array[0..255] of char;
begin
  if getlocaleinfoa(LOCALE_USER_DEFAULT, LOCALE_SSHORTDATE, b,
sizeof(b)) > 0 then
      writeln('LOCALE_USER_DEFAULT:',b);
  if getlocaleinfoa(LOCALE_SYSTEM_DEFAULT, LOCALE_SSHORTDATE, b,
sizeof(b)) > 0 then
      writeln('LOCALE_SYSTEM_DEFAULT:',b);
  if getlocaleinfoa(GetThreadLocale, LOCALE_SSHORTDATE, b, sizeof(b)) >
0 then
      writeln('GetThreadLocale:',b);
end;

In Windows XP/Vista returns:
LOCALE_USER_DEFAULT:d. M. yyyy
LOCALE_SYSTEM_DEFAULT:d. M. yyyy
GetThreadLocale:d. M. yyyy <--IS OK

In Windows 7 returns:
LOCALE_USER_DEFAULT:d. M. yyyy
LOCALE_SYSTEM_DEFAULT:d. M. yyyy
GetThreadLocale:M/d/yyyy <--HERE IS PROBLEM

So because calls to getlocaleinfo with argument GetThreadLocale is used to initialize DefaultFormatSettings, in Windows 7 are some locale specific global variables (ShortDateFormat, DateSeparator etc.) initialized incorrectly.
Has anybody else this experience ?

Now I find:
http://qc.embarcadero.com/wc/qcmain.aspx?d=80189
http://stackoverflow.com/questions/1767946/getthreadlocale-returns-different-value-than-getuserdefaultlcid

So can you fix this problem somewhere in initialization process ? Thanks
-Laco.

Reply by email

Unknown author
to LacaK
LacaK wrote 29 lines
Hi *, consider following sample program: var b: array[0..255] of char; begin if getlocaleinfoa(LOCALE_USER_DEFAULT, LOCALE_SSHORTDATE, b, sizeof(b)) > 0 then writeln('LOCALE_USER_DEFAULT:',b); if getlocaleinfoa(LOCALE_SYSTEM_DEFAULT, LOCALE_SSHORTDATE, b, sizeof(b)) > 0 then writeln('LOCALE_SYSTEM_DEFAULT:',b); if getlocaleinfoa(GetThreadLocale, LOCALE_SSHORTDATE, b, sizeof(b)) > 0 then writeln('GetThreadLocale:',b); end; In Windows XP/Vista returns: LOCALE_USER_DEFAULT:d. M. yyyy LOCALE_SYSTEM_DEFAULT:d. M. yyyy GetThreadLocale:d. M. yyyy <--IS OK In Windows 7 returns: LOCALE_USER_DEFAULT:d. M. yyyy LOCALE_SYSTEM_DEFAULT:d. M. yyyy GetThreadLocale:M/d/yyyy <--HERE IS PROBLEM So because calls to getlocaleinfo with argument GetThreadLocale is used to initialize DefaultFormatSettings, in Windows 7 are some locale specific global variables (ShortDateFormat, DateSeparator etc.) initialized incorrectly. Has anybody else this experience ?

Yes, in Delphi 7.

Show quoted text 6 lines

Please file a bugreport, citing the stackoverflow answer.

Michael.

Reply by email

LacaK
to Marco van de Voort: In our previous episode, LacaK said: More that the process begins. It is at least 3…

Hi *,
there are some waiting bugs with patches, which are relative simple and IMHO they can not affect negatively "product quality". I summarize them here, for quick review them, so if then they can go into 2.4.4 release:

1. http://bugs.freepascal.org/view.php?id=17188 and http://bugs.freepascal.org/view.php?id=18718
This fix add missing "cases" so all existing should work as before

2. http://bugs.freepascal.org/view.php?id=18649
This fix adds (or replaces) new datatype BIGINT to SQLite3Connection

3. http://bugs.freepascal.org/view.php?id=18670
This fix adds new datatype NCHAR, NVARCHAR, NCLOB to SQLite3Connection

4. http://bugs.freepascal.org/view.php?id=14944
This fix adds support for transactions in ODBCConnection

5. http://bugs.freepascal.org/view.php?id=16885
This fix adds missing TOracleConnection.RowsAffected method

6. http://bugs.freepascal.org/view.php?id=18699
This fixes Dialect 1 case

Thanks
-Laco.

Reply by email

Unknown author
to LacaK

I will look at them today.

Michael.

LacaK wrote 31 lines
Hi *, there are some waiting bugs with patches, which are relative simple and IMHO they can not affect negatively "product quality". I summarize them here, for quick review them, so if then they can go into 2.4.4 release: 1. http://bugs.freepascal.org/view.php?id=17188 and http://bugs.freepascal.org/view.php?id=18718 This fix add missing "cases" so all existing should work as before 2. http://bugs.freepascal.org/view.php?id=18649 This fix adds (or replaces) new datatype BIGINT to SQLite3Connection 3. http://bugs.freepascal.org/view.php?id=18670 This fix adds new datatype NCHAR, NVARCHAR, NCLOB to SQLite3Connection 4. http://bugs.freepascal.org/view.php?id=14944 This fix adds support for transactions in ODBCConnection 5. http://bugs.freepascal.org/view.php?id=16885 This fix adds missing TOracleConnection.RowsAffected method 6. http://bugs.freepascal.org/view.php?id=18699 This fixes Dialect 1 case Thanks -Laco. _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Unknown author
to Joost van der Sluis
Joost van der Sluis wrote 5 lines
On Wed, 2011-02-16 at 11:30 +0100, wrote: > I will look at them today. They all need improvement or a better review or testcases or break backwards compatibility.

The BIGINT or NCHAR stuff not, I would think ?

I'll have a look.

Michael.

Reply by email

Joost van der Sluis
to Unknown author
Show quoted text 12 lines
On Wed, 16 Feb 2011, Joost van der Sluis wrote: > On Wed, 2011-02-16 at 11:30 +0100, wrote: >> I will look at them today. > > They all need improvement or a better review or testcases or break > backwards compatibility. The BIGINT or NCHAR stuff not, I would think ? I'll have a look.

BIGINT leads to a backwards compatibility issue with largeint not being recognized anymore. (not a real problem I think, but it must be documented in user-changes) And I think to fix this a revision has to be reverted, not committed? Which leads to a new issue: we need to add a test that test for the problem introduced with the revision being reverted. (ie: recognition of fieldtypes when the first record is NULL)

The nchar stuff doesn't have tests. I don't even know if ftWideString and such are basic tests for these types have to be added.

Joost.

Reply by email

LacaK
to Joost van der Sluis
Show quoted text 11 lines
>> They all need improvement or a better review or testcases or break >> backwards compatibility. >> > The BIGINT or NCHAR stuff not, I would think ? > > I'll have a look. > BIGINT leads to a backwards compatibility issue with largeint not being recognized anymore. (not a real problem I think, but it must be documented in user-changes)

then we can leave "largeint" and add "bigint" this will be safe in all aspects. And largeint can be dropped later (as obsolete, non-standard).

Show quoted text 5 lines
And I think to fix this a revision has to be reverted, not committed? Which leads to a new issue: we need to add a test that test for the problem introduced with the revision being reverted. (ie: recognition of fieldtypes when the first record is NULL)

yes this problem was revealed, but does not affect fix as I wrote in bug tracker we must always rely on sqlite3_column_decltype() and only when no useful information will be available then use as workaround (or hack) sqlite3_column_type()

The nchar stuff doesn't have tests.

yes it is true, but they can be added later ... but NCHAR is not supported by all databases so it must be implemented carefully

I don't even know if ftWideString and such are me it works ... and as TWideStringField is descendant of

TStringField (which have tests), there is big chance, that it will work

The basic tests for these types have to be added.

if some patches are problematic, then leave it for future ... but please comment my list and let me know if I can do something to help. IMHO at least points 4,5,6 are safe.

Thanks
Laco.

Reply by email

LacaK
to Unknown author: I will look at them today. Michael.

Michael can you please look also at this
http://bugs.freepascal.org/view.php?id=17510
Thanks
Laco.

Show quoted text 42 lines
I will look at them today. Michael. On Wed, 16 Feb 2011, LacaK wrote: > Hi *, > there are some waiting bugs with patches, which are relative simple > and IMHO they can not affect negatively "product quality". > I summarize them here, for quick review them, so if then they can go > into 2.4.4 release: > > 1. http://bugs.freepascal.org/view.php?id=17188 and > http://bugs.freepascal.org/view.php?id=18718 > This fix add missing "cases" so all existing should work as before > > 2. http://bugs.freepascal.org/view.php?id=18649 > This fix adds (or replaces) new datatype BIGINT to SQLite3Connection > > 3. http://bugs.freepascal.org/view.php?id=18670 > This fix adds new datatype NCHAR, NVARCHAR, NCLOB to SQLite3Connection > > 4. http://bugs.freepascal.org/view.php?id=14944 > This fix adds support for transactions in ODBCConnection > > 5. http://bugs.freepascal.org/view.php?id=16885 > This fix adds missing TOracleConnection.RowsAffected method > > 6. http://bugs.freepascal.org/view.php?id=18699 > This fixes Dialect 1 case > > Thanks > -Laco. > _______________________________________________ > fpc-devel maillist - > http://lists.freepascal.org/mailman/listinfo/fpc-devel > _______________________________________________ fpc-devel maillist - http://lists.freepascal.org/mailman/listinfo/fpc-devel

Reply by email

Joost van der Sluis
to LacaK
LacaK wrote
>> 4. http://bugs.freepascal.org/view.php?id=14944 >> This fix adds support for transactions in ODBCConnection

Adding transactions so close to a release is not a good idea, imho. It could be added in trunk, though. But first run the testsuite with this patch for at least mysql/mssql and firebird using odbc.

>> 5. http://bugs.freepascal.org/view.php?id=16885 >> This fix adds missing TOracleConnection.RowsAffected method

A regression-test has to be performed before this can be comitted. (Needs an oracle setup)

>> 6. http://bugs.freepascal.org/view.php?id=18699 >> This fixes Dialect 1 case

The question in the bug-report has to be answered.

So even 4,5 and 6 are not that easy. (If they were, they were already applied)

Joost.

Reply by email

LacaK
to Joost van der Sluis

Hi Joost,
thanks for reply

Show quoted text 6 lines
>>> 4. http://bugs.freepascal.org/view.php?id=14944 >>> This fix adds support for transactions in ODBCConnection >>> Adding transactions so close to a release is not a good idea, imho. It could be added in trunk, though.

ok, no objections from me side
only to explain: ODBC works by default in auto-commit mode, and this behavior is not affected by fix so all remains as is. only when you supply to TODBCConnection.Params: 'Autocommit=false' or 'AutoCommit=0' you will switch to manual commit.
without this all works as before.

But first run the testsuite with this patch for at least mysql/mssql and firebird using odbc.

;-) please, no

Show quoted text 8 lines
>>> 5. http://bugs.freepascal.org/view.php?id=16885 >>> This fix adds missing TOracleConnection.RowsAffected method >>> A regression-test has to be performed before this can be comitted. (Needs an oracle setup)

Why do you think, that this patch can lead to problems, ATM RowsAffected is not implemented, so it always returns -1.
So nobody can use / rely on this value.
So I think, that provide some (untested) solution is better than nothing ... and we can wait for users feedback
(I do not have Oracle instaled, so I can not help, test)

Show quoted text 6 lines
>>> 6. http://bugs.freepascal.org/view.php?id=18699 >>> This fixes Dialect 1 case >>> The question in the bug-report has to be answered.

answered

So even 4,5 and 6 are not that easy. (If they were, they were already applied)

;-) ok

Thanks
Laco.

Reply by email

LacaK
to Joost van der Sluis: Adding transactions so close to a release is not a good idea, imho. It could be added in…

When I already have start this thread, I would like also point to this bugs (their are both more or less about the same): http://bugs.freepascal.org/view.php?id=14730
http://bugs.freepascal.org/view.php?id=18162

Now I can not primary talk about NULL paramters, but about ukInsert case (in Procedure TCustomSQLQuery.ApplyRecUpdate).
There is serious bug in fact, that FInsertQuery is assigned only once (using function InsertRecQuery), when FIRST insert is applied. And InsertRecQuery construct SQL insert but only for NOT NULL values.

Example:
1. we have table1 with some 3 columns: col1, col2, col3
2. I Append record and set only 1st column, then Post
3. I ApplyUpdates ... insert is constructed "INSERT INTO table1 (col1) VALUES(:col1)"
4. I Append second record and fill all 3 columns, then Post
5. I ApplyUpdates ... but no new insert is constructed (because FInsertQry is already assigned), but is used existing from step 3
6. So columns col2 and col3 are never inserted to database

Do you see ?

Thanks
Laco.

Reply by email