You are viewing a plain text version of this content. The canonical link for it is here.
Posted to embperl@perl.apache.org by Angus Lees <gu...@inodes.org> on 2002/09/18 05:12:26 UTC
DBIx::Recordset MoreRecords/Next bugs
with DBIx::Recordset 0.24 (with my debian bugfix patches applied.
these have been posted here previously), this simple loop works as
expected:
while (my $rec = $set->Next) {
print join(',', values %$rec), "\n";
#print 'morerecords=', ($set->MoreRecords ? 'yes' : 'no'), "\n";
}
uncommenting the "morerecords" line causes the loop to endlessly print
the last record (on my 2 result query).
the problem is that MoreRecords() fetches the next row, which gets
cached in *LastRecord/*LastRecordFetch. The next Next() hits this
cache, returning _before_updating_*LastRow_. Following Next()s will
then keep refetching this same row.
from looking at the FETCH() code, this "cache" doesn't actually
achieve much (the code path for a hit on $data->[$fetch] is already
pretty quick); so i chose to simply remove the cache check altogether,
rather than duplicate later *FetchMax sanity checks, etc again.
this revealed another problem: Next() tries to work out whether to
fetch the first row or the next row based on whether anything had been
fetched before (whether $self->{'*LastRecord'} is defined).
it needs to do this so that $set->Reset, followed by $set->Next gets
the first row in the table.
when the DBI statement is finished (DBIx::Recordset has read all
results), the last record retrieved (*LastRecord) is undef (thats how
DBI tells you you've reached the end in fact). Next() thus thinks
we're starting again (or something), doesn't increment the "last row"
counter and ends up using *LastRow again.
since *LastRecord seems to be used in other places to imply various
things, i just changed Reset() and Next() to use *LastRecordFetch to
signify "the row before the first". just to be safe, i undefine
*LastRecordFetch when a new SQLSelect is performed.
(more discussion after patch)
--- /tmp/libdbix-recordset-perl.orig/Recordset.pm Wed Sep 18 12:23:42 2002
+++ /home/gus/src/libdbix-recordset-perl-0.24/Recordset.pm Wed Sep 18 12:23:42 2002
@@ -1314,6 +1314,7 @@
$self->{'*EOD'} = undef ;
$self->{'*SelectFields'} = undef ;
$self->{'*LastRecord'} = undef ;
+ $self->{'*LastRecordFetch'} = undef ;
$order ||= '' ;
$expr ||= '' ;
@@ -1469,8 +1470,6 @@
$fetch += $self->{'*FetchStart'} ;
- return $self->{'*LastRecord'} if (defined ($self->{'*LastRecordFetch'}) && $fetch == $self->{'*LastRecordFetch'} && $self->{'*LastRecord'}) ;
-
my $max ;
my $key ;
my $dat ; # row data
@@ -1656,6 +1655,7 @@
my $self = shift ;
$self->{'*LastRecord'} = undef ;
+ $self->{'*LastRecordFetch'} = undef ;
$self ->{'*LastRow'} = 0 ;
}
@@ -1708,7 +1708,7 @@
$lr -= $self -> {'*FetchStart'} ;
$lr = 0 if ($lr < 0) ;
- $lr++ if (defined ($self -> {'*LastRecord'})) ;
+ $lr++ if (defined ($self -> {'*LastRecordFetch'})) ;
##$lr++ if ($_[0] ->{'*CurrRow'} > 0 || $_[0] ->{'*EOD'}) ;
my $rec = $self -> FETCH ($lr) ;
this passes "make test" on DBD::Pg, after applying the following
test.pl patch. PostgreSQL (rightfully, imo) gives a fatal error when
trying to do '.. WHERE value1="String"' when value1 is of type INT.
the DBI::SQL_* changes were necessary, since they're interpreted as
strings otherwise (thanks to '=>'). i can't see how the previous
version could ever have worked.. cleaner would probably be to import
:sql_types from DBI directly.
--- /tmp/libdbix-recordset-perl.orig/test.pl Wed Sep 18 12:35:37 2002
+++ /home/gus/src/libdbix-recordset-perl-0.24/test.pl Wed Sep 18 12:35:37 2002
@@ -921,23 +921,29 @@
printlogf "Select multiply fields 2";
print LOG "\n--------------------\n" ;
+ if ($Driver eq 'Pg') {
+ print "skipped\n";
+ } else {
$set1 -> Select ({'+name&value1' => "Third Name",
'$operator' => '='}) or die "not ok ($DBI::errstr)" ;
Check ($Driver eq 'CSV'?[3]:[3, 14], $TestFields[0], \@set1) or print "ok\n" ;
-
+ }
# ---------------------
printlogf "Select multiply fields & values";
print LOG "\n--------------------\n" ;
+ if ($Driver eq 'Pg') {
+ print "skipped\n";
+ } else {
$set1 -> Select ({'+name&value1' => "Second Name\t9991",
'$operator' => '='}) or die "not ok ($DBI::errstr)" ;
Check ($Driver eq 'CSV'?[1,2]:[1,2,14], $TestFields[0], \@set1) or print "ok\n" ;
-
+ }
# ---------------------
$set1 -> Search ({id => 1,name => 'First Name',addon => 'Is'}) or die "not ok ($DBI::errstr)" ;
@@ -1412,6 +1418,9 @@
printlogf "Search multfield *<field>";
print LOG "\n--------------------\n" ;
+ if ($Driver eq 'Pg') {
+ print "skipped\n";
+ } else {
$set6 -> Search ({"+$t0\lid|$t0\laddon" => "7\tit",
"$t0\lname" => 'Fourth Name',
"\*$t0\lid" => '<',
@@ -1420,6 +1429,7 @@
'$conj' => 'and' }) or die "not ok ($DBI::errstr)" ;
Check ([1,2,3,5,6,10], ['id', 'name', 'txt'], \@set6) or print "ok\n" ;
+ }
# ---------------------
@@ -1428,6 +1438,9 @@
printlogf "Search \$compconj";
print LOG "\n--------------------\n" ;
+ if ($Driver eq 'Pg') {
+ print "skipped\n";
+ } else {
$set6 -> Search ({"+$t0\lid|$t0\laddon" => "6\tit",
"$t0\lname" => 'Fourth Name',
"\*$t0\lid" => '>',
@@ -1444,6 +1457,7 @@
{
Check ([1,3,4,5,7,8,9,10,11], ['id', 'name', 'txt'], \@set6) or print "ok\n" ;
}
+ }
# ---------------------
@@ -3588,12 +3602,12 @@
'name2' => '05.10.99',
'!Filter' =>
{
- DBI::SQL_CHAR =>
+ DBI::SQL_CHAR() =>
[
sub { shift =~ /(\d\d)\.(\d\d)\.(\d\d)/ ; "19$3$2$1"},
sub { shift =~ /\d\d(\d\d)(\d\d)(\d\d)/ ; "$3.$2.$1"}
],
- DBI::SQL_VARCHAR =>
+ DBI::SQL_VARCHAR() =>
[
sub { shift =~ /(\d\d)\.(\d\d)\.(\d\d)/ ; "19$3$2$1"},
sub { shift =~ /\d\d(\d\d)(\d\d)(\d\d)/ ; "$3.$2.$1"}
@@ -3688,12 +3702,12 @@
$db -> TableAttr ($Table[1], '!Filter',
{
- DBI::SQL_CHAR =>
+ DBI::SQL_CHAR() =>
[
sub { shift =~ /(\d\d)\.(\d\d)\.(\d\d)/ ; "19$3$2$1"},
sub { shift =~ /\d\d(\d\d)(\d\d)(\d\d)/ ; "$3.$2.$1"}
],
- DBI::SQL_VARCHAR =>
+ DBI::SQL_VARCHAR() =>
[
sub { shift =~ /(\d\d)\.(\d\d)\.(\d\d)/ ; "19$3$2$1"},
sub { shift =~ /\d\d(\d\d)(\d\d)(\d\d)/ ; "$3.$2.$1"}
--
- Gus
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Session support
Posted by Angus Lees <gu...@inodes.org>.
At Sat, 28 Sep 2002 12:32:37 +0200, Kaare Rasmussen wrote:
> But another thing re sessions. I'm thinking about adding an "updated" column
> and a trigger or something to be able to clean out old unused sessions.
>
> Or does Apache::Session(X) magically keep track of them?
no, and its actually a feature i'd like Apache::SessionX to do somehow.
especially for dbm, where there is no way to add a "last accessed
time" for each entry.
note that you really want "last accessed time", not "last modified
time" if thats possible (it mightn't be).
--
- Gus
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Session support
Posted by Gerald Richter <ri...@ecos.de>.
>
> But another thing re sessions. I'm thinking about adding an "updated"
column
> and a trigger or something to be able to clean out old unused sessions.
>
> Or does Apache::Session(X) magically keep track of them?
>
Not yet, also I would like to see the Apache::SessionX does keep track of
update and last access times to be able to cleanup old sessions. In my
developement version here I have already some code for iterating over all
session, which could be handy for expiring old sessions.
If anybody likes to add these times to Apache::SessionX I would be happy to
give some advice how to start...
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Session support
Posted by Kaare Rasmussen <ka...@kakidata.dk>.
> note that the latest version or two of DBD::Pg actually reports
> correct SQL types to DBI (which is probably why my DBIx::Recordset
> tests are failing now) and correctly escapes the binary BYTEA type.
OK, so I will try a bytea column with Storable. I don't think there will be a
big performance win, but I'd like to know that the installation is optimal.
But another thing re sessions. I'm thinking about adding an "updated" column
and a trigger or something to be able to clean out old unused sessions.
Or does Apache::Session(X) magically keep track of them?
--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2501
Howitzvej 75 Åben 12.00-18.00 Email: kar@kakidata.dk
2000 Frederiksberg Lørdag 12.00-16.00 Web: www.suse.dk
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Session support
Posted by Angus Lees <gu...@inodes.org>.
At Sat, 28 Sep 2002 05:27:32 +0200, Gerald Richter wrote:
> > Not sure what is the best for serialization. Bas64, Dumper, ...??
> > I haven't been able to find any discussion about pro / con for this.
>
> As far as I know you should use Base64 for Postgres
note that the latest version or two of DBD::Pg actually reports
correct SQL types to DBI (which is probably why my DBIx::Recordset
tests are failing now) and correctly escapes the binary BYTEA type.
so you can probably (untested) use a BYTEA column for your binary
session data (which comes from Storable) and it will Just Work.
(previous versions of DBD::Pg and postgres couldn't cope with 8bit
data, hence the Base64 step)
--
- Gus (happy to see DBD::Pg development pick up again)
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Session support
Posted by Gerald Richter <ri...@ecos.de>.
>
> Not sure what is the best for serialization. Bas64, Dumper, ...??
> I haven't been able to find any discussion about pro / con for this.
>
As far as I know you should use Base64 for Postgres
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Session support
Posted by Angus Lees <gu...@inodes.org>.
At Thu, 26 Sep 2002 16:15:10 +0200, Kaare Rasmussen wrote:
> Thanks. I got it to work with
> Postgres Semaphore Base64
that will work, but you should be using "Postgres Null Base64"
> Not sure what is the best for serialization. Bas64, Dumper, ...??
> I haven't been able to find any discussion about pro / con for this.
Storable -> Base64 is the usual way for postgres. I should think that
the time/size you gain in using Storable rather than Data::Dumper
probably outweighs the cost of the extra Base64 step.
--
- Gus
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Session support
Posted by Kaare Rasmussen <ka...@kakidata.dk>.
> in there somewhere will be the actual SQL statement being used, which
> should give some clues as to whats going wrong.
Thanks. I got it to work with
Postgres Semaphore Base64
Not sure what is the best for serialization. Bas64, Dumper, ...??
I haven't been able to find any discussion about pro / con for this.
--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2501
Howitzvej 75 Åben 12.00-18.00 Email: kar@kakidata.dk
2000 Frederiksberg Lørdag 12.00-16.00 Web: www.suse.dk
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Session support
Posted by Kaare Rasmussen <ka...@kakidata.dk>.
> Yes, but you don't need any locking for Postgres. Use the Null locker,
> Postgres itself takes care for data integrity. Then you can use it across
> multiple Apaches.
Thanks. I will try that out.
> Which parameters do give to Apache::SessionX Makefile.PL ?
I found an old message about the same problem. I think the answer was to set
the parameters to Postgres Semaphore Base64. I got it to work, but I will
try it out with Null instead of Semaphore.
Not sure about Base64. Is this the best setting?
--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2501
Howitzvej 75 Åben 12.00-18.00 Web: www.suse.dk
2000 Frederiksberg Lørdag 12.00-16.00 Email:kar@kakidata.dk
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Session support
Posted by Gerald Richter <ri...@ecos.de>.
> I'm trying to set up session support for Embperl.
>
> I'd like to use Postgres, so my application can scale better. But it seems
> that it uses semaphores for locking, and that the semaphores is placed on
> Apache's side. Wouldn't this prevent me from using two or more Apache
> servers from runing the same application with one database server?
>
Yes, but you don't need any locking for Postgres. Use the Null locker,
Postgres itself takes care for data integrity. Then you can use it across
multiple Apaches.
> But my current question is that I get a strange error. After fighting off
> semaphore and other problems, I'm stuck with this:
>
> [2811]ERR: 24: Error in Perl code: DBD::Pg::st execute failed: ERROR:
> Unterminated quoted string at
> /usr/lib/perl5/site_perl/5.6.1/Apache/Session/Store/DBI.pm line 42.
>
>
Which parameters do give to Apache::SessionX Makefile.PL ?
Does make test runs ok for Apache::SessionX?
Gerald
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Session support
Posted by Angus Lees <gu...@inodes.org>.
At Tue, 24 Sep 2002 07:44:29 GMT, Kaare Rasmussen wrote:
> I'm trying to set up session support for Embperl.
> I'd like to use Postgres, so my application can scale better. But it seems
> that it uses semaphores for locking, and that the semaphores is placed on
> Apache's side. Wouldn't this prevent me from using two or more Apache
> servers from runing the same application with one database server?
yes it would, if you were using something other than postgres for
storage.
you should use the "Null" locker for postgres, since the postgres
store does its own locking (using postgres transactions).
> But my current question is that I get a strange error. After fighting off
> semaphore and other problems, I'm stuck with this:
>
> [2811]ERR: 24: Error in Perl code: DBD::Pg::st execute failed: ERROR:
> Unterminated quoted string at
> /usr/lib/perl5/site_perl/5.6.1/Apache/Session/Store/DBI.pm line 42.
> Line 42 in DBI.pm is an execute of an insert into the sessions table. Can
> anyone help me or offer any hints?
set the DBI_TRACE environment variable to /tmp/dbi.log (or something),
then start apache. all DBI calls should now log several lines to that
log file.
in there somewhere will be the actual SQL statement being used, which
should give some clues as to whats going wrong.
--
- Gus
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Session support
Posted by Kaare Rasmussen <ka...@kakidata.dk>.
I'm trying to set up session support for Embperl.
I'd like to use Postgres, so my application can scale better. But it seems
that it uses semaphores for locking, and that the semaphores is placed on
Apache's side. Wouldn't this prevent me from using two or more Apache
servers from runing the same application with one database server?
But my current question is that I get a strange error. After fighting off
semaphore and other problems, I'm stuck with this:
[2811]ERR: 24: Error in Perl code: DBD::Pg::st execute failed: ERROR:
Unterminated quoted string at
/usr/lib/perl5/site_perl/5.6.1/Apache/Session/Store/DBI.pm line 42.
Apache/1.3.26 (Unix) Embperl/2.0b8 PHP/4.2.2 mod_perl/1.27 [Mon Sep 23
22:32:28 2002]
Line 42 in DBI.pm is an execute of an insert into the sessions table. Can
anyone help me or offer any hints?
--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2501
Howitzvej 75 Åben 12.00-18.00 Web: www.suse.dk
2000 Frederiksberg Lørdag 12.00-16.00 Email:kar@kakidata.dk
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: DBIx::Recordset array
Posted by Gerald Richter <ri...@ecos.de>.
> I have an orderheader with a couple of orderlines.
>
> I want to process the whole array of orderlines at once.
>
> As far as I can tell the only way is to loop through the resultset and
fill
> a new array from that. Is that correct, or does a more direct way exist.
>
> To be more specific - I have to process the orderlines in a transaction
> together with the orderheader. This can only be done when the user accepts
> the full order. In the mean time, any changes to orderlines will have to
be
> volatile. So the idea is to put the array of orderlines into %udat.
>
Sounds ok to me
Gerald
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
DBIx::Recordset array
Posted by Kaare Rasmussen <ka...@kakidata.dk>.
I have an orderheader with a couple of orderlines.
I want to process the whole array of orderlines at once.
As far as I can tell the only way is to loop through the resultset and fill
a new array from that. Is that correct, or does a more direct way exist.
To be more specific - I have to process the orderlines in a transaction
together with the orderheader. This can only be done when the user accepts
the full order. In the mean time, any changes to orderlines will have to be
volatile. So the idea is to put the array of orderlines into %udat.
--
Kaare Rasmussen --Linux, spil,-- Tlf: 3816 2582
Kaki Data tshirts, merchandize Fax: 3816 2501
Howitzvej 75 Åben 12.00-18.00 Web: www.suse.dk
2000 Frederiksberg Lørdag 12.00-16.00 Email:kar@kakidata.dk
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: DBIx::Recordset MoreRecords/Next bugs
Posted by Gerald Richter <ri...@ecos.de>.
Hi Angus,
thanks for the patch. Seems to make sense, but I have to go thru it more in
details as soon as I have a little bit more time...
Gerald
-------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
Internetconnect * Webserver/-design/-datenbanken * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 925131
WWW: http://www.ecos.de Fax: +49 6133 925152
-------------------------------------------------------------
----- Original Message -----
From: "Angus Lees" <gu...@inodes.org>
To: <em...@perl.apache.org>
Sent: Wednesday, September 18, 2002 5:12 AM
Subject: DBIx::Recordset MoreRecords/Next bugs
>
> with DBIx::Recordset 0.24 (with my debian bugfix patches applied.
> these have been posted here previously), this simple loop works as
> expected:
>
> while (my $rec = $set->Next) {
> print join(',', values %$rec), "\n";
> #print 'morerecords=', ($set->MoreRecords ? 'yes' : 'no'), "\n";
> }
>
> uncommenting the "morerecords" line causes the loop to endlessly print
> the last record (on my 2 result query).
>
>
> the problem is that MoreRecords() fetches the next row, which gets
> cached in *LastRecord/*LastRecordFetch. The next Next() hits this
> cache, returning _before_updating_*LastRow_. Following Next()s will
> then keep refetching this same row.
>
>
> from looking at the FETCH() code, this "cache" doesn't actually
> achieve much (the code path for a hit on $data->[$fetch] is already
> pretty quick); so i chose to simply remove the cache check altogether,
> rather than duplicate later *FetchMax sanity checks, etc again.
>
>
> this revealed another problem: Next() tries to work out whether to
> fetch the first row or the next row based on whether anything had been
> fetched before (whether $self->{'*LastRecord'} is defined).
>
> it needs to do this so that $set->Reset, followed by $set->Next gets
> the first row in the table.
>
> when the DBI statement is finished (DBIx::Recordset has read all
> results), the last record retrieved (*LastRecord) is undef (thats how
> DBI tells you you've reached the end in fact). Next() thus thinks
> we're starting again (or something), doesn't increment the "last row"
> counter and ends up using *LastRow again.
>
> since *LastRecord seems to be used in other places to imply various
> things, i just changed Reset() and Next() to use *LastRecordFetch to
> signify "the row before the first". just to be safe, i undefine
> *LastRecordFetch when a new SQLSelect is performed.
>
> (more discussion after patch)
>
> --- /tmp/libdbix-recordset-perl.orig/Recordset.pm Wed Sep 18 12:23:42 2002
> +++ /home/gus/src/libdbix-recordset-perl-0.24/Recordset.pm Wed Sep 18
12:23:42 2002
> @@ -1314,6 +1314,7 @@
> $self->{'*EOD'} = undef ;
> $self->{'*SelectFields'} = undef ;
> $self->{'*LastRecord'} = undef ;
> + $self->{'*LastRecordFetch'} = undef ;
>
> $order ||= '' ;
> $expr ||= '' ;
> @@ -1469,8 +1470,6 @@
>
> $fetch += $self->{'*FetchStart'} ;
>
> - return $self->{'*LastRecord'} if (defined
($self->{'*LastRecordFetch'}) && $fetch == $self->{'*LastRecordFetch'} &&
$self->{'*LastRecord'}) ;
> -
> my $max ;
> my $key ;
> my $dat ; # row data
> @@ -1656,6 +1655,7 @@
> my $self = shift ;
>
> $self->{'*LastRecord'} = undef ;
> + $self->{'*LastRecordFetch'} = undef ;
> $self ->{'*LastRow'} = 0 ;
> }
>
> @@ -1708,7 +1708,7 @@
>
> $lr -= $self -> {'*FetchStart'} ;
> $lr = 0 if ($lr < 0) ;
> - $lr++ if (defined ($self -> {'*LastRecord'})) ;
> + $lr++ if (defined ($self -> {'*LastRecordFetch'})) ;
>
> ##$lr++ if ($_[0] ->{'*CurrRow'} > 0 || $_[0] ->{'*EOD'}) ;
> my $rec = $self -> FETCH ($lr) ;
>
>
>
> this passes "make test" on DBD::Pg, after applying the following
> test.pl patch. PostgreSQL (rightfully, imo) gives a fatal error when
> trying to do '.. WHERE value1="String"' when value1 is of type INT.
>
> the DBI::SQL_* changes were necessary, since they're interpreted as
> strings otherwise (thanks to '=>'). i can't see how the previous
> version could ever have worked.. cleaner would probably be to import
> :sql_types from DBI directly.
>
>
> --- /tmp/libdbix-recordset-perl.orig/test.pl Wed Sep 18 12:35:37 2002
> +++ /home/gus/src/libdbix-recordset-perl-0.24/test.pl Wed Sep 18 12:35:37
2002
> @@ -921,23 +921,29 @@
> printlogf "Select multiply fields 2";
> print LOG "\n--------------------\n" ;
>
> + if ($Driver eq 'Pg') {
> + print "skipped\n";
> + } else {
> $set1 -> Select ({'+name&value1' => "Third Name",
> '$operator' => '='}) or die "not ok
($DBI::errstr)" ;
>
>
> Check ($Driver eq 'CSV'?[3]:[3, 14], $TestFields[0], \@set1) or print
"ok\n" ;
> -
> + }
> # ---------------------
>
> printlogf "Select multiply fields & values";
> print LOG "\n--------------------\n" ;
>
> + if ($Driver eq 'Pg') {
> + print "skipped\n";
> + } else {
> $set1 -> Select ({'+name&value1' => "Second Name\t9991",
> '$operator' => '='}) or die "not ok
($DBI::errstr)" ;
>
>
> Check ($Driver eq 'CSV'?[1,2]:[1,2,14], $TestFields[0], \@set1) or
print "ok\n" ;
> -
> + }
> # ---------------------
>
> $set1 -> Search ({id => 1,name => 'First Name',addon => 'Is'}) or
die "not ok ($DBI::errstr)" ;
> @@ -1412,6 +1418,9 @@
> printlogf "Search multfield *<field>";
> print LOG "\n--------------------\n" ;
>
> + if ($Driver eq 'Pg') {
> + print "skipped\n";
> + } else {
> $set6 -> Search ({"+$t0\lid|$t0\laddon" => "7\tit",
> "$t0\lname" => 'Fourth Name',
> "\*$t0\lid" => '<',
> @@ -1420,6 +1429,7 @@
> '$conj' => 'and' }) or die "not
ok ($DBI::errstr)" ;
>
> Check ([1,2,3,5,6,10], ['id', 'name', 'txt'], \@set6) or print
"ok\n" ;
> + }
>
> # ---------------------
>
> @@ -1428,6 +1438,9 @@
> printlogf "Search \$compconj";
> print LOG "\n--------------------\n" ;
>
> + if ($Driver eq 'Pg') {
> + print "skipped\n";
> + } else {
> $set6 -> Search ({"+$t0\lid|$t0\laddon" => "6\tit",
> "$t0\lname" => 'Fourth Name',
> "\*$t0\lid" => '>',
> @@ -1444,6 +1457,7 @@
> {
> Check ([1,3,4,5,7,8,9,10,11], ['id', 'name', 'txt'], \@set6) or
print "ok\n" ;
> }
> + }
>
>
> # ---------------------
> @@ -3588,12 +3602,12 @@
> 'name2' => '05.10.99',
> '!Filter' =>
> {
> - DBI::SQL_CHAR =>
> + DBI::SQL_CHAR() =>
>
> sub { shift =~ /(\d\d)\.(\d\d)\.(\d\d)/ ; "19$3$2$1"},
> sub { shift =~ /\d\d(\d\d)(\d\d)(\d\d)/ ; "$3.$2.$1"}
> ],
> - DBI::SQL_VARCHAR =>
> + DBI::SQL_VARCHAR() =>
>
> sub { shift =~ /(\d\d)\.(\d\d)\.(\d\d)/ ; "19$3$2$1"},
> sub { shift =~ /\d\d(\d\d)(\d\d)(\d\d)/ ; "$3.$2.$1"}
> @@ -3688,12 +3702,12 @@
>
> $db -> TableAttr ($Table[1], '!Filter',
> {
> - DBI::SQL_CHAR =>
> + DBI::SQL_CHAR() =>
>
> sub { shift =~ /(\d\d)\.(\d\d)\.(\d\d)/ ; "19$3$2$1"},
> sub { shift =~ /\d\d(\d\d)(\d\d)(\d\d)/ ; "$3.$2.$1"}
> ],
> - DBI::SQL_VARCHAR =>
> + DBI::SQL_VARCHAR() =>
>
> sub { shift =~ /(\d\d)\.(\d\d)\.(\d\d)/ ; "19$3$2$1"},
> sub { shift =~ /\d\d(\d\d)(\d\d)(\d\d)/ ; "$3.$2.$1"}
>
>
> --
> - Gus
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
> For additional commands, e-mail: embperl-help@perl.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org