r51124 - in /branches/upstream/liborlite-perl/current: Changes META.yml README lib/ORLite.pm t/08_prune.pl t/lib/Test.pm
jawnsy-guest at users.alioth.debian.org
jawnsy-guest at users.alioth.debian.org
Sun Jan 17 18:05:11 UTC 2010
Author: jawnsy-guest
Date: Sun Jan 17 18:04:22 2010
New Revision: 51124
URL: http://svn.debian.org/wsvn/pkg-perl/?sc=1&rev=51124
Log:
[svn-upgrade] Integrating new upstream version, liborlite-perl (1.32)
Modified:
branches/upstream/liborlite-perl/current/Changes
branches/upstream/liborlite-perl/current/META.yml
branches/upstream/liborlite-perl/current/README
branches/upstream/liborlite-perl/current/lib/ORLite.pm
branches/upstream/liborlite-perl/current/t/08_prune.pl
branches/upstream/liborlite-perl/current/t/lib/Test.pm
Modified: branches/upstream/liborlite-perl/current/Changes
URL: http://svn.debian.org/wsvn/pkg-perl/branches/upstream/liborlite-perl/current/Changes?rev=51124&op=diff
==============================================================================
--- branches/upstream/liborlite-perl/current/Changes (original)
+++ branches/upstream/liborlite-perl/current/Changes Sun Jan 17 18:04:22 2010
@@ -1,4 +1,20 @@
Changes for Perl extension ORLite
+
+1.32 Fri 15 Jan 2010
+ - Each generated class now cleans up its own persistant
+ connection, rather than allowing it to fall through to the
+ deeper DBI cleanup.
+ - To allow for persistant connections to readonly database,
+ we now always built transaction support for all databases.
+ However, for readonly databases we do not build the commit
+ method and you may only use the rollback method to end them.
+ - Significantly expanded the Pod documentation to provide
+ documentation on all of the import options.
+ - Add support for a cleanup option to import, which is single
+ explicit statement to be called on the database when the
+ process is shutting down. This should typically be used
+ ensure that a SQLite database is VACUUM'ed regularly (and at
+ a time when it hopefully won't impact the user much).
1.31 Sat 2 Jan 2010
- Adding explicit versioned-use lines to the generated code (in case
Modified: branches/upstream/liborlite-perl/current/META.yml
URL: http://svn.debian.org/wsvn/pkg-perl/branches/upstream/liborlite-perl/current/META.yml?rev=51124&op=diff
==============================================================================
--- branches/upstream/liborlite-perl/current/META.yml (original)
+++ branches/upstream/liborlite-perl/current/META.yml Sun Jan 17 18:04:22 2010
@@ -34,4 +34,4 @@
ChangeLog: http://fisheye2.atlassian.com/changelog/cpan/trunk/ORLite
license: http://dev.perl.org/licenses/
repository: http://svn.ali.as/cpan/trunk/ORLite
-version: 1.31
+version: 1.32
Modified: branches/upstream/liborlite-perl/current/README
URL: http://svn.debian.org/wsvn/pkg-perl/branches/upstream/liborlite-perl/current/README?rev=51124&op=diff
==============================================================================
--- branches/upstream/liborlite-perl/current/README (original)
+++ branches/upstream/liborlite-perl/current/README Sun Jan 17 18:04:22 2010
@@ -16,20 +16,22 @@
package Bar;
- # All available options enabled
- # Some options shown are mutually exclusive, this would not actually run
+ # All available options enabled or specified.
+ # Some options shown are mutually exclusive,
+ # this code would not actually run.
use ORLite {
package => 'My::ORM',
file => 'data/sqlite.db',
user_version => 12,
- tables => [ 'table1', 'table2' ],
readonly => 1,
- prune => 1,
create => sub {
my $dbh = shift;
$dbh->do('CREATE TABLE foo ( bar TEXT NOT NULL )');
},
+ tables => [ 'table1', 'table2' ],
+ cleanup => 'VACUUM',
+ prune => 1,
);
DESCRIPTION
@@ -61,7 +63,7 @@
Further documentation will be available at a later time, but the
synopsis gives a pretty good idea of how it works.
-How it Works
+ How ORLite Works
In short, ORLite discovers the schema of a SQLite database, and then
uses code generation to build a set of packages for talking to that
database.
@@ -76,6 +78,176 @@
Then it will create one sub-package underneath the root package for each
table contained in the database.
+
+OPTIONS
+ ORLite takes a set of options for the class construction at compile time
+ as a HASH parameter to the "use" line.
+
+ As a convenience, you can pass just the name of an existing SQLite file
+ to load, and ORLite will apply defaults to all other options.
+
+ # The following are equivalent
+
+ use ORLite $filename;
+
+ use ORLite {
+ file => $filename,
+ };
+
+ The behaviour of each of the options is as follows:
+
+ package
+ The optional "package" parameter is used to provide the Perl root
+ namespace to generate the code for. This class does not need to exist as
+ a module on disk, nor does it need to have anything loaded or in the
+ namespace.
+
+ By default, the package used is the package that is calling ORLite's
+ import method (typically via the "use ORLite { ... }" line).
+
+ file
+ The compulsory "file" parameter (the only compulsory parameter) provides
+ the path to the SQLite file to use for the ORM class tree.
+
+ If the file already exists, it must be a valid SQLite file match that
+ supported by the version of DBD::SQLite that is installed on your
+ system.
+
+ ORLite will throw an exception if the file does not exist, unless you
+ also provide the "create" option to signal that ORLite should create a
+ new SQLite file on demand.
+
+ If the "create" option is provided, the path provided must be creatable.
+ When creating the database, ORLite will also create any missing
+ directories as needed.
+
+ user_version
+ When working with ORLite, the biggest risk to the stability of your code
+ is often the reliability of the SQLite schema structure over time.
+
+ When the database schema changes the code generated by ORLite will also
+ change. This can easily result in an unexpected change in the API of
+ your class tree, breaking the code that sits on top of those generated
+ APIs.
+
+ To resolve this, ORLite supports a feature called schema
+ version-locking.
+
+ Via the "user_version" SQLite pragma, you can set a revision for your
+ database schema, increasing the number each time to make a non-trivial
+ chance to your schema.
+
+ SQLite> PRAGMA user_version = 7
+
+ When creating your ORLite package, you should specificy this schema
+ version number via the "user_version" option.
+
+ use ORLite {
+ file => $filename,
+ user_version => 7,
+ };
+
+ When connecting to the SQLite database, the "user_version" you provide
+ will be checked against the version in the schema. If the versions do
+ not match, then the schema has unexpectedly changed, and the code that
+ is generated by ORLite would be different to the expected API.
+
+ Rather than risk potentially destructive errors caused by the changing
+ code, ORLite will simply refuse to run and throw an exception.
+
+ Thus, using the "user_version" feature allows you to write code against
+ a SQLite database with high-certainty that it will continue to work. Or
+ at the very least, that should the SQLite schema change in the future
+ your code fill fail quickly and safely instead of running away and
+ causing unknown behaviour.
+
+ By default, the "user_version" option is false and the value of the
+ SQLite "PRAGMA user_version" will not be checked.
+
+ readonly
+ To conserve memory and reduce complexity, ORLite will generate the API
+ differently based on the writability of the SQLite database.
+
+ Features like transaction support and methods that result in "INSERT",
+ "UPDATE" and "DELETE" queries will only be added if they can actually be
+ run, resulting in an immediate "no such method" exception at the Perl
+ level instead of letting the application do more work only to hit an
+ inevitable SQLite error.
+
+ By default, the "reaodnly" option is based on the filesystem permissions
+ of the SQLite database (which matches SQLite's own writability
+ behaviour).
+
+ However the "readonly" option can be explicitly provided if you wish.
+ Generally you would do this if you are working with a read-write
+ database, but you only plan to read from it.
+
+ Forcing "readonly" to true will halve the size of the code that is
+ generated to produce your ORM, reducing the size of any auto-generated
+ API documentation using ORLite::Pod by a similar amount.
+
+ It also ensures that this process will only take shared read locks on
+ the database (preventing the chance of creating a dead-lock on the
+ SQLite database).
+
+ create
+ The "create" option is used to expand ORLite beyond just consuming other
+ people's databases to produce and operating on databases user the direct
+ control of your code.
+
+ The "create" option supports two alternative forms.
+
+ If "create" is set to a simple true value, an empty SQLite file will be
+ created if the location provided in the "file" option does not exist.
+
+ If "create" is set to a "CODE" reference, this function will be executed
+ on the new database before ORLite attempts to scan the schema.
+
+ The "CODE" reference will be passed a plain DBI connection handle, which
+ you should operate on normally. Note that because "create" is fired
+ before the code generation phase, none of the functionality produced by
+ the generated classes is available during the execution of the "create"
+ code.
+
+ The use of "create" option is incompatible with the "readonly" option.
+
+ tables
+ The "tables" option should be a reference to an array containing a list
+ of table names. For large or complex SQLite databases where you only
+ need to make use of a fraction of the schema limiting the set of tables
+ will reduce both the startup time needed to scan the structure of the
+ SQLite schema, and reduce the memory cost of the class tree.
+
+ If the "tables" option is not provided, ORLite will attempt to produce a
+ class for every table in the main schema that is not prefixed with with
+ "sqlite_".
+
+ cleanup
+ When working with embedded SQLite database containing rapidly changing
+ state data, it is important for database performance and general health
+ to make sure you VACUUM or ANALYZE the database regularly.
+
+ The "cleanup" option should be a single literal SQL statement.
+
+ If provided, this statement will be automatically run on the database
+ during "END"-time, after the last transaction has been completed.
+
+ This will typically either by a full 'VACUUM ANALYZE' or the more simple
+ 'VACUUM'.
+
+ prune
+ In some situation, such as during test scripts, an application will only
+ need the created SQLite database temporarily. In these situations, the
+ "prune" option can be provided to instruct ORLite to delete the SQLite
+ database when the program ends.
+
+ If any directories were made in order to create the SQLite file, these
+ directories will be cleaned up and removed as well.
+
+ If "prune" is enabled, you should generally not use "cleanup" as any
+ cleanup operation will be made pointless when "prune" deletes the file.
+
+ By default, the "prune" option is set to false.
ROOT PACKAGE METHODS
All ORLite root packages receive an identical set of methods for
@@ -143,6 +315,12 @@
Returns true or throws an exception on error.
+ While transaction support is always built for every ORLite-generated
+ class tree, if the database is opened "readonly" the "commit" method
+ will not exist at all in the API, and your only way of ending the
+ transaction (and the resulting persistant connection) will be
+ "rollback".
+
commit
Foo::Bar->commit;
@@ -155,6 +333,38 @@
transaction, you will need to issue a separate ->begin call.
Returns true or throws an exception on error.
+
+ commit_begin
+ Foo::Bar->begin;
+
+ # Code for the first transaction...
+
+ Foo::Bar->commit_begin;
+
+ # Code for the last transaction...
+
+ Foo::Bar->commit;
+
+ By default, ORLite-generated code uses opportunistic connections.
+
+ Every <select> you call results in a fresh DBI "connect", and a
+ "disconnect" occurs after query processing and before the data is
+ returned. Connections are only held open indefinitely during a
+ transaction, with an immediate "disconnect" after your "commit".
+
+ This makes ORLite very easy to use in an ad-hoc manner, but can have
+ performance implications.
+
+ While SQLite itself can handle 1000 connections per second, the repeated
+ destruction and repopulation of SQLite's data page caches between your
+ statements (or between transactions) can slow things down dramatically.
+
+ The "commit_begin" method is used to "commit" the current transaction
+ and immediately start a new transaction, without disconnecting from the
+ database.
+
+ Its exception behaviour and return value is identical to that of a plain
+ "commit" call.
rollback
The "rollback" method rolls back the current transaction. If called
@@ -169,6 +379,38 @@
automatically rolled back.
Returns true or throws an exception on error.
+
+ rollback_begin
+ Foo::Bar->begin;
+
+ # Code for the first transaction...
+
+ Foo::Bar->rollback_begin;
+
+ # Code for the last transaction...
+
+ Foo::Bar->commit;
+
+ By default, ORLite-generated code uses opportunistic connections.
+
+ Every <select> you call results in a fresh DBI "connect", and a
+ "disconnect" occurs after query processing and before the data is
+ returned. Connections are only held open indefinitely during a
+ transaction, with an immediate "disconnect" after your "commit".
+
+ This makes ORLite very easy to use in an ad-hoc manner, but can have
+ performance implications.
+
+ While SQLite itself can handle 1000 connections per second, the repeated
+ destruction and repopulation of SQLite's data page caches between your
+ statements (or between transactions) can slow things down dramatically.
+
+ The "rollback_begin" method is used to "rollback" the current
+ transaction and immediately start a new transaction, without
+ disconnecting from the database.
+
+ Its exception behaviour and return value is identical to that of a plain
+ "commit" call.
do
Foo::Bar->do('insert into table (foo, bar) values (?, ?)', {},
Modified: branches/upstream/liborlite-perl/current/lib/ORLite.pm
URL: http://svn.debian.org/wsvn/pkg-perl/branches/upstream/liborlite-perl/current/lib/ORLite.pm?rev=51124&op=diff
==============================================================================
--- branches/upstream/liborlite-perl/current/lib/ORLite.pm (original)
+++ branches/upstream/liborlite-perl/current/lib/ORLite.pm Sun Jan 17 18:04:22 2010
@@ -15,7 +15,7 @@
use vars qw{$VERSION};
BEGIN {
- $VERSION = '1.31';
+ $VERSION = '1.32';
}
# Support for the 'prune' option
@@ -76,6 +76,9 @@
unless ( defined $params{readonly} ) {
$params{readonly} = $params{create} ? 0 : ! -w $params{file};
}
+ unless ( defined $params{cleanup} ) {
+ $params{cleanup} = '';
+ }
unless ( defined $params{tables} ) {
$params{tables} = 1;
}
@@ -98,10 +101,11 @@
}
$class->prune($file) if $params{prune};
}
- my $pkg = $params{package};
- my $readonly = $params{readonly};
- my $dsn = "dbi:SQLite:$file";
- my $dbh = DBI->connect( $dsn, undef, undef, {
+ my $pkg = $params{package};
+ my $readonly = $params{readonly};
+ my $cleanup = $params{cleanup};
+ my $dsn = "dbi:SQLite:$file";
+ my $dbh = DBI->connect( $dsn, undef, undef, {
PrintError => 0,
RaiseError => 1,
} );
@@ -193,16 +197,35 @@
\$sth->finish;
}
-END_PERL
-
- # Add transaction support if not readonly
- $code .= <<"END_PERL" unless $readonly;
sub begin {
\$DBH or
\$DBH = \$_[0]->connect;
\$DBH->begin_work;
}
+sub rollback {
+ \$DBH or return 1;
+ \$DBH->rollback;
+ \$DBH->disconnect;
+ undef \$DBH;
+ return 1;
+}
+
+sub rollback_begin {
+ if ( \$DBH ) {
+ \$DBH->rollback;
+ \$DBH->begin_work;
+ } else {
+ \$_[0]->begin;
+ }
+ return 1;
+}
+
+END_PERL
+
+ # If you are a read-write database, we even allow you
+ # to commit your transactions.
+ $code .= <<"END_PERL" unless $readonly;
sub commit {
\$DBH or return 1;
\$DBH->commit;
@@ -221,25 +244,25 @@
return 1;
}
-sub rollback {
- \$DBH or return 1;
- \$DBH->rollback;
- \$DBH->disconnect;
- undef \$DBH;
- return 1;
-}
-
-sub rollback_begin {
- if ( \$DBH ) {
- \$DBH->rollback;
- \$DBH->begin_work;
+END_PERL
+
+ # Cleanup and shutdown operations
+ if ( $cleanup ) {
+ $code .= <<"END_PERL";
+END {
+ \$dbh->rollback if \$DBH;
+ $pkg->dbh->do('$cleanup');
+}
+
+END_PERL
} else {
- \$_[0]->begin;
- }
- return 1;
+ $code .= <<"END_PERL";
+END {
+ $pkg->rollback if \$DBH;
}
END_PERL
+ }
# Optionally generate the table classes
if ( $params{tables} ) {
@@ -506,20 +529,22 @@
package Bar;
- # All available options enabled
- # Some options shown are mutually exclusive, this would not actually run
+ # All available options enabled or specified.
+ # Some options shown are mutually exclusive,
+ # this code would not actually run.
use ORLite {
package => 'My::ORM',
file => 'data/sqlite.db',
user_version => 12,
- tables => [ 'table1', 'table2' ],
readonly => 1,
- prune => 1,
create => sub {
my $dbh = shift;
$dbh->do('CREATE TABLE foo ( bar TEXT NOT NULL )');
},
+ tables => [ 'table1', 'table2' ],
+ cleanup => 'VACUUM',
+ prune => 1,
);
=head1 DESCRIPTION
@@ -551,7 +576,7 @@
Further documentation will be available at a later time, but the synopsis
gives a pretty good idea of how it works.
-=head1 How it Works
+=head2 How ORLite Works
In short, ORLite discovers the schema of a SQLite database, and then uses
code generation to build a set of packages for talking to that database.
@@ -566,6 +591,181 @@
Then it will create one sub-package underneath the root package for each
table contained in the database.
+
+=head1 OPTIONS
+
+ORLite takes a set of options for the class construction at compile time
+as a HASH parameter to the "use" line.
+
+As a convenience, you can pass just the name of an existing SQLite file
+to load, and ORLite will apply defaults to all other options.
+
+ # The following are equivalent
+
+ use ORLite $filename;
+
+ use ORLite {
+ file => $filename,
+ };
+
+The behaviour of each of the options is as follows:
+
+=head2 package
+
+The optional C<package> parameter is used to provide the Perl root namespace to generate
+the code for. This class does not need to exist as a module on disk,
+nor does it need to have anything loaded or in the namespace.
+
+By default, the package used is the package that is calling ORLite's import
+method (typically via the C<use ORLite { ... }> line).
+
+=head2 file
+
+The compulsory C<file> parameter (the only compulsory parameter) provides
+the path to the SQLite file to use for the ORM class tree.
+
+If the file already exists, it must be a valid SQLite file match that
+supported by the version of L<DBD::SQLite> that is installed on your
+system.
+
+L<ORLite> will throw an exception if the file does not exist, B<unless>
+you also provide the C<create> option to signal that L<ORLite> should
+create a new SQLite file on demand.
+
+If the C<create> option is provided, the path provided must be creatable.
+When creating the database, L<ORLite> will also create any missing
+directories as needed.
+
+=head2 user_version
+
+When working with ORLite, the biggest risk to the stability of your code
+is often the reliability of the SQLite schema structure over time.
+
+When the database schema changes the code generated by ORLite will also
+change. This can easily result in an unexpected change in the API of your
+class tree, breaking the code that sits on top of those generated APIs.
+
+To resolve this, L<ORLite> supports a feature called schema version-locking.
+
+Via the C<user_version> SQLite pragma, you can set a revision for your
+database schema, increasing the number each time to make a non-trivial
+chance to your schema.
+
+ SQLite> PRAGMA user_version = 7
+
+When creating your L<ORLite> package, you should specificy this schema
+version number via the C<user_version> option.
+
+ use ORLite {
+ file => $filename,
+ user_version => 7,
+ };
+
+When connecting to the SQLite database, the C<user_version> you provide
+will be checked against the version in the schema. If the versions do
+not match, then the schema has unexpectedly changed, and the code that
+is generated by L<ORLite> would be different to the expected API.
+
+Rather than risk potentially destructive errors caused by the changing
+code, L<ORLite> will simply refuse to run and throw an exception.
+
+Thus, using the C<user_version> feature allows you to write code against
+a SQLite database with high-certainty that it will continue to work. Or
+at the very least, that should the SQLite schema change in the future your
+code fill fail quickly and safely instead of running away and causing
+unknown behaviour.
+
+By default, the C<user_version> option is false and the value of
+the SQLite C<PRAGMA user_version> will B<not> be checked.
+
+=head2 readonly
+
+To conserve memory and reduce complexity, L<ORLite> will generate the API
+differently based on the writability of the SQLite database.
+
+Features like transaction support and methods that result in C<INSERT>,
+C<UPDATE> and C<DELETE> queries will only be added if they can actually
+be run, resulting in an immediate "no such method" exception at the Perl
+level instead of letting the application do more work only to hit an
+inevitable SQLite error.
+
+By default, the C<reaodnly> option is based on the filesystem permissions
+of the SQLite database (which matches SQLite's own writability behaviour).
+
+However the C<readonly> option can be explicitly provided if you wish.
+Generally you would do this if you are working with a read-write database,
+but you only plan to read from it.
+
+Forcing C<readonly> to true will halve the size of the code that is
+generated to produce your ORM, reducing the size of any auto-generated
+API documentation using L<ORLite::Pod> by a similar amount.
+
+It also ensures that this process will only take shared read locks on the
+database (preventing the chance of creating a dead-lock on the SQLite
+database).
+
+=head2 create
+
+The C<create> option is used to expand L<ORLite> beyond just consuming
+other people's databases to produce and operating on databases user the
+direct control of your code.
+
+The C<create> option supports two alternative forms.
+
+If C<create> is set to a simple true value, an empty SQLite file will be
+created if the location provided in the C<file> option does not exist.
+
+If C<create> is set to a C<CODE> reference, this function will be executed
+on the new database B<before> L<ORLite> attempts to scan the schema.
+
+The C<CODE> reference will be passed a plain L<DBI> connection handle,
+which you should operate on normally. Note that because C<create> is fired
+before the code generation phase, none of the functionality produced by
+the generated classes is available during the execution of the C<create>
+code.
+
+The use of C<create> option is incompatible with the C<readonly> option.
+
+=head2 tables
+
+The C<tables> option should be a reference to an array containing a list
+of table names. For large or complex SQLite databases where you only need
+to make use of a fraction of the schema limiting the set of tables
+will reduce both the startup time needed to scan the structure of the
+SQLite schema, and reduce the memory cost of the class tree.
+
+If the C<tables> option is not provided, L<ORLite> will attempt to produce
+a class for every table in the main schema that is not prefixed with
+with C<sqlite_>.
+
+=head2 cleanup
+
+When working with embedded SQLite database containing rapidly changing
+state data, it is important for database performance and general health
+to make sure you VACUUM or ANALYZE the database regularly.
+
+The C<cleanup> option should be a single literal SQL statement.
+
+If provided, this statement will be automatically run on the database
+during C<END>-time, after the last transaction has been completed.
+
+This will typically either by a full C<'VACUUM ANALYZE'> or the more
+simple C<'VACUUM'>.
+
+=head2 prune
+
+In some situation, such as during test scripts, an application will only
+need the created SQLite database temporarily. In these situations, the
+C<prune> option can be provided to instruct L<ORLite> to delete the
+SQLite database when the program ends.
+
+If any directories were made in order to create the SQLite file, these
+directories will be cleaned up and removed as well.
+
+If C<prune> is enabled, you should generally not use C<cleanup> as any
+cleanup operation will be made pointless when C<prune> deletes the file.
+
+By default, the C<prune> option is set to false.
=head1 ROOT PACKAGE METHODS
@@ -637,6 +837,11 @@
Returns true or throws an exception on error.
+While transaction support is always built for every L<ORLite>-generated
+class tree, if the database is opened C<readonly> the C<commit> method
+will not exist at all in the API, and your only way of ending the
+transaction (and the resulting persistant connection) will be C<rollback>.
+
=head2 commit
Foo::Bar->commit;
@@ -650,6 +855,39 @@
Returns true or throws an exception on error.
+=head2 commit_begin
+
+ Foo::Bar->begin;
+
+ # Code for the first transaction...
+
+ Foo::Bar->commit_begin;
+
+ # Code for the last transaction...
+
+ Foo::Bar->commit;
+
+By default, L<ORLite>-generated code uses opportunistic connections.
+
+Every <select> you call results in a fresh L<DBI> C<connect>, and a
+C<disconnect> occurs after query processing and before the data is
+returned. Connections are B<only> held open indefinitely during a
+transaction, with an immediate C<disconnect> after your C<commit>.
+
+This makes ORLite very easy to use in an ad-hoc manner, but can have
+performance implications.
+
+While SQLite itself can handle 1000 connections per second, the repeated
+destruction and repopulation of SQLite's data page caches between your
+statements (or between transactions) can slow things down dramatically.
+
+The C<commit_begin> method is used to C<commit> the current transaction
+and immediately start a new transaction, without disconnecting from the
+database.
+
+Its exception behaviour and return value is identical to that of a plain
+C<commit> call.
+
=head2 rollback
The C<rollback> method rolls back the current transaction. If called outside
@@ -663,6 +901,39 @@
automatically rolled back.
Returns true or throws an exception on error.
+
+=head2 rollback_begin
+
+ Foo::Bar->begin;
+
+ # Code for the first transaction...
+
+ Foo::Bar->rollback_begin;
+
+ # Code for the last transaction...
+
+ Foo::Bar->commit;
+
+By default, L<ORLite>-generated code uses opportunistic connections.
+
+Every <select> you call results in a fresh L<DBI> C<connect>, and a
+C<disconnect> occurs after query processing and before the data is
+returned. Connections are B<only> held open indefinitely during a
+transaction, with an immediate C<disconnect> after your C<commit>.
+
+This makes ORLite very easy to use in an ad-hoc manner, but can have
+performance implications.
+
+While SQLite itself can handle 1000 connections per second, the repeated
+destruction and repopulation of SQLite's data page caches between your
+statements (or between transactions) can slow things down dramatically.
+
+The C<rollback_begin> method is used to C<rollback> the current transaction
+and immediately start a new transaction, without disconnecting from the
+database.
+
+Its exception behaviour and return value is identical to that of a plain
+C<commit> call.
=head2 do
Modified: branches/upstream/liborlite-perl/current/t/08_prune.pl
URL: http://svn.debian.org/wsvn/pkg-perl/branches/upstream/liborlite-perl/current/t/08_prune.pl?rev=51124&op=diff
==============================================================================
--- branches/upstream/liborlite-perl/current/t/08_prune.pl (original)
+++ branches/upstream/liborlite-perl/current/t/08_prune.pl Sun Jan 17 18:04:22 2010
@@ -4,7 +4,7 @@
use strict;
-our $VERSION = '1.31';
+our $VERSION = '1.32';
unless ( $ORLite::VERSION eq $VERSION ) {
die('Failed to load correct ORLite version');
Modified: branches/upstream/liborlite-perl/current/t/lib/Test.pm
URL: http://svn.debian.org/wsvn/pkg-perl/branches/upstream/liborlite-perl/current/t/lib/Test.pm?rev=51124&op=diff
==============================================================================
--- branches/upstream/liborlite-perl/current/t/lib/Test.pm (original)
+++ branches/upstream/liborlite-perl/current/t/lib/Test.pm Sun Jan 17 18:04:22 2010
@@ -8,7 +8,7 @@
use vars qw{$VERSION @ISA @EXPORT};
BEGIN {
- $VERSION = '1.31';
+ $VERSION = '1.32';
@ISA = 'Exporter';
@EXPORT = qw{ test_db connect_ok create_ok };
}
More information about the Pkg-perl-cvs-commits
mailing list