Re: Unicode and Sybase univarchar
On Fri, 4 Jun 2010, Alexander Foken wrote: Right. (But remember that DBI was there before Unicode support was added to Perl, and also most DBDs are older that the Unicode support. Before Unicode was there, you just passed bytes around and everything just worked.) Only if by everything you exclude any and all operations that need to be character aware, such as length, substr, regexes, encoding, etc. That's why I proposed to switch to DBD::ODBC: It is well tested and supports Unicode as good as the ODBC driver does. And as I said in private email, that's not really feasible for us. Now you "just" need to find someone who is willing and has the time to patch DBD::Sybase ... ;-) Which is why I'm hoping we can pay Michael to work on this. Clearly, he's the most qualified. Otherwise, I might have to do this, which is a scary thought. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Unicode and Sybase univarchar
On Thu, 3 Jun 2010, Alexander Foken wrote: Really strange way to avoid pack()/unpack(). At least, you can get rid of the Yes, yes, this is hack code, not production. ... should just work. It doesn't quite, because the hex string is not just a dump of a 16 Bit Unicode encoding, but it is a UTF-8 byte stream written with a 16 Bit Hex Format for each byte. Each and every 16-Bit-Word has its most significant byte set to 0. If it was a dump of a 16 Bit Unicode encoding, it should read "0065006d00200064006100730068003a00202014" and not "0065006d00200064006100730068003a002000e200800094" Your call to decode() compensates that, probably because you encoded once too much before writing the data into the database. I did not encode at all. I simply created a utf8 string in Perl land and inserted it into Sybase. Really, DBD::Sybase needs to handle any character set translation, not the end user. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Unicode and Sybase univarchar
On Thu, 3 Jun 2010, Michael Peppler wrote: 2010/06/03 14:08:11 unicode CRITICAL: FATAL: DBD::Sybase::db do failed: Server message number=2402 severity=16 state=1 line=1 server=HDATADEV1 text=Error converting characters into server's character set. Some character(s) could not be converted. I'm not sure what that means. Hmmm - is that on a query, or on an insert operation? That was from an insert. If I _don't_ set that, the data goes in and comes out as bytes, rather than the bizarro hex string. However, the data does have the utf8 flag set when it comes back from Sybase, so I have to run it through Encode::decode. I really don't think I can realistically tell the bazillion developers here "just run all the data through Encode". I'd really like see an end-to-end solution. I agree - I've just not had much opportunity (or requests) to ensure that this works 100%. Ideally if you could send me some sample code, and a simple table structure and data that reproduces the problem for you I could try to look at it and see if I can fix it. See my previous email. I included some code, and there was a table definition after the __END__ marker. As I said, my employer might be willing to pay to have this done. If that's something you're interested, let's talk off list and I can try to help coordinate that. Also, it's not clear to me that the data is actually being stored as characters at the Sybase level. I'm not even sure how I'd figure this out. When I do a select from sqsh, I see the wacky hex string, but I can't tell if that's Sybase trying to present data to me in a format it thinks my environment can handle. When in doubt - use the Sybase tools (i.e. isql, and use -Jutf8 to force conversion to/from utf8 when reading/writing the data). Unfortunately, from the terminal on my work dev machine, this gives me the hex string. I think something is being "helpful" here ;) I fiddled with -Jutf8 and setting LC_ALL, to no avail. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Unicode and Sybase univarchar
On Thu, 3 Jun 2010, Dave Rolsky wrote: If I _don't_ set that, the data goes in and comes out as bytes, rather than the bizarro hex string. However, the data does have the utf8 flag set when it comes back from Sybase, so I have to run it through Encode::decode. Doh, the data _does not_ have the utf8 flag set. That's what I meant to say. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Unicode and Sybase univarchar
On Thu, 3 Jun 2010, Michael Peppler wrote: Which version of Sybase, which version of Sybase OpenClient, and which version of DBD::Sybase? Ah, I was using the old libs (11.0), which may have been the problem. I was also using DBD::Sybase 1.07. I switch to Sybase 15.0 (OCS 15.0 if that makes sense), OpenClient 15.0 libs, and DBD::Sybase 1.10. Now it's closer to working. If I set "charset=utf8" in the dsn, I get 2010/06/03 14:08:11 unicode CRITICAL: FATAL: DBD::Sybase::db do failed: Server message number=2402 severity=16 state=1 line=1 server=HDATADEV1 text=Error converting characters into server's character set. Some character(s) could not be converted. I'm not sure what that means. If I _don't_ set that, the data goes in and comes out as bytes, rather than the bizarro hex string. However, the data does have the utf8 flag set when it comes back from Sybase, so I have to run it through Encode::decode. I really don't think I can realistically tell the bazillion developers here "just run all the data through Encode". I'd really like see an end-to-end solution. Also, it's not clear to me that the data is actually being stored as characters at the Sybase level. I'm not even sure how I'd figure this out. When I do a select from sqsh, I see the wacky hex string, but I can't tell if that's Sybase trying to present data to me in a format it thinks my environment can handle. I did try setting LC_ALL=us_english.utf8 when running sqsh, but that didn't make a difference. Basically, what I need is to be able to take Perl native unicode strings, store them in Sybase in Sybase's native format (utf16, I believe), and then retrieve them as Perl native unicode strings again. -dave /* http://VegGuide.org http://blog.urth.org Your guide to all that's veg House Absolute(ly Pointless) */
Re: Unicode and Sybase univarchar
On Thu, 3 Jun 2010, Michael Peppler wrote:
I just gave this a try - I'm under linux, with ASE 15.5. I created a table with
a univarchar column, entered some data via isql, then wrote a minimal perl
script to fetch the data.
If I use a UTF8 locale (i.e. LANG=en_us.UTF8) I get the correct output.
If I don't I do not get the correct output, at least for rows where non-ascii
data has been entered into the table.
Define correct output here. From looking at the DBD::Sybase code, I don't
see how it could possibly be right, because there's nothing in there to
set the utf8 flag on the Perl string when the data is retrieved.
So even if I can work around the bizarro "bytes as a string" issue, I
still won't have utf8 after the round trip.
My test script did something like this:
my $dbh = ...; # set charset to utf8
round_trip("em dash: \x{2014}");
sub round_trip {
my $unicode = shift;
$dbh->do('DELETE FROM unicode');
check($unicode);
$dbh->do( 'INSERT INTO unicode (utest) VALUES (?)', {}, $unicode );
my $rows = $dbh->selectall_arrayref('SELECT * FROM unicode');
my $fromdb = $rows->[0][0];
check($fromdb);
my $chars = do {
use bytes;
join q{}, map { chr( eval '0x' . $_ ) } $fromdb =~ /()/g;
};
check($chars);
my $decoded = decode( 'utf-8', $chars );
check($decoded);
}
sub check {
my $string = shift;
print "$string is utf8? ",
( Encode::is_utf8($string) ? 'yes' : 'no' ),
"\n";
}
__END__
CREATE TABLE unicode (
utest univarchar(250) NOT NULL,
);
-dave
/*
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
*/
Unicode and Sybase univarchar
I'm working on an i18n project, and we use Sybase (sigh).
Newer versions of Sybase have built-in support for Unicode with the
univarchar (and other uni*) type.
However, it seems like DBD::Sybase doesn't have any support for this.
Specifically, if I take a Perl unicode string (utf8 flag is on) and insert
it in a univarchar column, it seems to be inserted as raw bytes (or
something).
What's really bizarre is that when I select the value back I get something
like "0065006d00200064006100730068003a002000e200800094".
Yes, that's a literal string containing a series of 2-digit hex numbers!
I can translate this back to Perl unicode with this madness:
my $chars = do {
use bytes;
join q{}, map { chr( eval '0x' . $_ ) } $fromdb =~ /()/g;
};
my $unicode = decode( 'utf8', $chars );
So the data is there, but not in a very usable form.
Has anyone researched or solved this problem?
Michael Peppler, if you're reading this, is there any work on supporting
Perl's unicode format transparently in DBD::Sybase?
My employer might be able to pay to have this work done, if you're
interested. Alternately, maybe you could give me some hints and I could
try to figure it out.
-dave
/*
http://VegGuide.org http://blog.urth.org
Your guide to all that's veg House Absolute(ly Pointless)
*/
ANNOUNCE: Alzabo 0.87
0.87 May 14, 2005 BUG FIXES: - Table names in CREATE INDEX statements for Postgres were not quoted. - Database names in CREATE/DROP DATABASE statements for Postgres were not quoted. - Postgres database names with upper case characters were never being detected as being instantiated, which meant Alzabo always tried to recreate the schema from scratch. - ALTER TABLE statements for Postgres left the table name unquoted when renaming a column. - Even if Alzabo::Runtime::Schema->referential_integrity was false, Alzabo was still doing referential integrity checking on inserts. Reported by Michal Jurosz. - 19-schema-name.t did not use the user-supplied connection parameters and could fail because of this. Reported by Daniel Puro. - Handle quotes in table names returned by Postgres when reverse engineering. - Reverse engineering a Postgres schema that contained indexes on functions could fail because the Alzabo::RDBMSRules::PostgreSQL code used a function from Text::Balanced without loading it first (or making it a prereq for the distro). Reported by an anonymous user via rt.cpan.org. - When getting the next sequence number from a Postgres schema, Alzabo was not quoting the sequence name even if the schema's quote_identifiers attribute was true. Reported by "Martin" via rt.cpan.org. ENHANCEMENTS: - Allow any key starting with "pg_" when connecting a Postgres database. This allows you to pass attributes like "pg_enable_utf8" or "pg_bool_tf". Prompted by a discussion with Boris Shomodjvarac. -dave /*=== VegGuide.Orgwww.BookIRead.com Your guide to all that's veg. My book blog ===*/
ANNOUNCE: Alzabo 0.86
0.86 December 22, 2004 BUG FIXES: - Allow a UNIQUE constraint as a column attribute for MySQL. ENHANCEMENTS: - It is now possible to use a single Alzabo schema object to create and access multiple copies of that schema in an RDBMS. This is done by setting the "schema_name" parameter whenever calling a method that accesses the RDBMS. This feature has a bad interaction with the way internal schema diffs are generated, however. Please see the "MULTIPLE COPIES OF THE SAME SCHEMA" section in Alzabo::Intro for details. - The Alzabo::Runtime::Row->update() method now returns a boolean indicating whether any changes where actually made. Patch by Eric Waters. /*=== VegGuide.Org Your guide to all that's veg. ===*/
ANNOUNCE: Alzabo 0.85
0.85 October 12, 2004 BUG FIXES: - The DECIMAL and NUMERIC column types in MySQL were not being treated as numeric types. This meant that you couldn't give such a column the UNSIGNED attribute, among other problems. Reported by Bob Sidebotham. - If a column had CHECK constraints, the Postgres reverse engineering failed. Reported by Ken Miller, fixed by Joshua Jore. - Insert handles did not include sequenced Postgres columns, causing 17-insert-handle.t to fail when run against Postgres. Reported by Eric Schwartz. -dave /*=== VegGuide.Org Your guide to all that's veg. ===*/
ANNOUNCE: Alzabo 0.84
0.84 September 4, 2004 ENHANCEMENTS: - Alzabo::MethodMaker will now warn you when you it creates a method that overrides a parent class's method. This can cause problems when you override the table class's name() method with one that returns a column object. BUG FIXES - Make Alzabo::Create::Schema->delete work under taint mode. Reported by Dana Hudes. - Improve Alazbo::PostgreSQL docs, specifically mentioning that if you create a Postgres schema with mixed or upper case table names, you need to do $schema->set_quote_identifiers(1) for any DML SQL to work. - The Alzabo::Runtime::Row->is_potential method didn't exist. - The caching had a very nasty interaction with reverse engineering that could cause data loss (of foreign keys) when the "sync with backend" functionality was called from the Mason GUI. There may have been other bugs as well. This was fixed by not caching reverse engineered schemas, which is somewhat of a hack. Anyone using the Mason GUI with MySQL is encouraged to upgrade because of this bug. /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: Alzabo 0.83
0.83 June 9, 2003 MISCELLANEOUS: - I got fed up with the instability of CVS on Sourceforge, and am now using a Subversion repository I host myself. See "source" page on www.alzabo.org for details. ENHANCEMENTS: - All SQL-generating methods for the Alzabo::Runtime::Schema and Alzabo::Runtime::Table classes now accept a "quote_identifiers" parameter, which allows you to turn this on for a single query. - Improved handling of MySQL's "default defaults" when reverse engineering or comparing two schemas, so that the code doesn't generate ALTER TABLE statements that don't do anything. - Make many Params::Validate specs into constants, which may improve speed a bit, and may affect memory usage under mod_perl. This is probably a useless micro-optimization, though. BUG FIXES - Make sure generated SQL for Postgres schema diffs does not include dropping & adding the same FK constraint more than once. - Reverse engineering works with Postgres 7.4. Thanks to Josh Jore for this big patch. Hopefully this won't break anything for Postgres 7.3 ;) - The Alzabo::Column->is_time_interval method was misspelled, and so did not work at all. Patch from Josh Jore. - With Postgres 7.4, the DBI tables method always includes system tables, so we have to filter these out in the Alzabo::Driver::PostgreSQL->tables method. Patch from Josh Jore. - Make the is_date & is_datetime method consistent across various databases. For Postgres, is_date was only returning true for the DATE type, not TIMESTAMP. - Make is_datetime return true for Postgres' TIMESTAMPTZ column type. - Turning on SQL debugging could cause Alzabo to alter bound values that were null to the string "NULL" before performing a query. - If a table name was changed and an index, column, or foreign key dropped from that table, then the generated "diff" SQL could refer to the old table name in the various DROP statements that were generated. - Workaround a bug in MySQL that reports a "Sub_part" of 1 for fulltext indexes. - The changes introduced in 0.71 to track table and column renames could cause bogus SQL to be generated if something was renamed, the schema was instantiated, and then the schema was compared to an existing live database which also had the same renaming done to it. - If you tried to create a relationship between two tables where one of the tables had a varchar or char column as part of its PK, and you let Alzabo create the foreign key column in the other table, then Alzabo would try to set the length of the varchar/char column to undef, which would cause an exception to be thrown. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
DBI and overload are not happy together
Here's a simple recipe to reproduce this:
my $dbh = DBI->connect(...);
print "overloaded\n" overload::Overloaded($dbh);
The error that comes out is:
can: handle 'DBI::db' is not a hash reference at dbi.pl line 9.
This is coming from DBI, because the Overloaded function looks like this:
sub Overloaded {
my $package = shift;
$package = ref $package if ref $package;
$package->can('()');
}
I have no idea why Overloaded insists on calling can on the package
instead of the object, but that really doesn't seem like something that
should cause a fatal error, does it?
-dave
/*===
House Absolute Consulting
www.houseabsolute.com
===*/
ANNOUNCE: Alzabo 0.82
0.82 January 6, 2003 ENHANCEMENTS: - The Alzabo::Runtime::Table->insert() and Alzabo::Runtime::InsertHandle->insert() will not create a new row object when called in void context. This should make inserts faster when you don't need a row object back. - When reverse engineering a MySQL schema, Alzabo will now set a table attribute for the table type (MyISAM, InnoDB, etc.) if the server supports table types (which any modern version of MySQL does do). BUG FIXES: - When creating the test database for MySQL, we now explicitly set the table type to MYISAM, in case the default is something else. Otherwise the tests will fail when we try to create a fulltext index. KNOWN BUGS: - This release will fail several tests when tested with Postgres 7.4. Specifically, reverse engineering with Postgres 7.4 is known to be broken. This will be fixed in the next release. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: Alzabo 0.81
0.81 December 21, 2003 ENHANCEMENTS: - Added a new insert handle feature, which should be significantly faster for batch inserts than repeatedly calling the table class's insert() method. Development funded by Marigold Technologies. BUG FIXES: - An order_by parameter that contained two SQL functions (like "COUNT(*) DESC, AVG(score) DESC") caused the error "A sort specifier cannot follow another sort specifier in an ORDER BY clause". - If you passed a no_cache parameter to a method that created a row, this would cause an error unless Alzabo::Runtime::UniqueRowCache had been loaded. - Workaround for bug/change/something in DBD::Pg 1.31+ that affects the $dbh->tables method, which broke reverse engineering. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: Alzabo 0.80
Well, here it is. The big 0.80 release. Please note that this release has quite a number of backwards incompatibilities. The biggest of these is that the old caching system is gone. If you were using it, you won't get an error when you load it, because the modules will probably still be on your system, but they won't actually do anything! Thanks again to Ken Williams and Ilya Martynov, who were both big contributors towards this release. The changes below includes all the changes between the last stable version (0.73) and 0.80. 0.80 October 24, 2003 ENHANCEMENTS: - Use the non-deprecated form of DBI->tables(). - Added an is_time_interval method to Alzabo::Column. - Lots and lots of doc cleanup and re-formatting. 0.79_04 October 18, 2003 Identical to 0.79_03 except for minor POD changes in order to try to fix the problem of search.cpan.org treating the wrong file as the main Alzabo.pm docs. Again reported by Darren Duncan. 0.79_03 October 18, 2003 ENHANCEMENTS: - Many doc rewrites and updates. - Documented row state classes. - Added back the no_cache parameter to avoid caching one or more rows. - Moved the relevant documentation from Alzabo::Runtime::PotentialRow into Alzabo::Runtime::Row. BUG FIXES: - Fixed the NAME portion of the Alzabo::MySQL and Alzabo::PostgreSQL POD files so that search.cpan.org doesn't think Alzabo::MySQL is the Alzabo.pm file. Reported by Darren Duncan. - The 12-rev_engineer_pg_fk.t test would try to load DBD::Pg even if you weren't using Postgres, which would cause the test file to die if DBD::Pg wasn't installed. Reported by Jost's smokehouse. - More documentation updates to remove outdated information. - Split out the documentation in Alzabo.pm into Alzabo::Intro and Alzabo::Design. - Added a FAQ from a question on the mailing list. Suggested by Terrence Brannon. - Eliminated a circular reference between tables created via the Alzabo::Runtime::Table->alias() method, and the columns those alias tables contain. This required the use of weak references. NOTE: Alzabo regular tables and columns have circular references to each other, but this normally isn't a problem because you generally want to keep a whole schema around all the time anyway. 0.79_02 October 17, 2003 ENHANCEMENTS: - Added support for table attributes like MySQL's "TYPE = ..." or Postgres's "WITH OIDS". - Added support for functional indexes in Postgres, like "LOWER(some_col)". Funded by Kineticode, Inc. for Bricolage 2.0. - Added column/table constraint/check reverse engineering for Postgres. Funded by Kineticode, Inc. for Bricolage 2.0. - The SQL generated for Postgres schemas now includes foreign key constraints. - Added a new method to Alzabo::Runtime::Schema, prefetch_none(). - Added a new method to Alzabo::Table, has_index(). - Documented Alzabo::Runtime::UniqueRowCache. - The definitions of the is_character and is_blob column methods have been clarified. Note that these definitions have changed from the previous, undefined behavior. - When a 1..1 or 1..n foreign key is added to a table, a unique index is created on the columns involved in the foreign key, unless those columns are part of the table's primary key. BUG FIXES: - Fixed a problem in the Makefile.PL which would cause it to fail even if you had Module::Build installed. Reported by Ken Williams. - Fixed (really, this time, I hope) a problem where the user-provided connection parameters were not respected in the 01-driver.t tests. Reported by Ken Williams. - FK reverse engineering for Postgres sometimes got the cardinality of the relationship wrong, making it 1..1 when it should be 1..n. This should be much improved in this release, though it may still have bugs. - Removed references to the old caching code in various spots. - Fixed handling of case_sensitive parameter to Alzabo::Column->has_attribute(). BACKWARDS INCOMPATIBILITIES: - When you load a runtime schema, it now calls "$self->prefetch_all_but_blobs" in order to turn on pre-fetching by default, since for the vast majority of users, this is a huge performance improvement. The new prefetch_none() method can be used to turn off all prefetching. - The is_character column method now returns true for any text type column, regardless of size. - The is_blob column method now returns true only for columns that are defined to hold binary data. 0.79_01 October 10, 2003 ENHANCEMENTS: - Distribution is now signed with Module::Signature. - Lots of refactoring of the row object internals to simplify the code. Implemented by Ilya Martynov. - The testing code has been cleaned up quite a bit, and all of the utility functions used in the tests have been consolidated in t/lib/Alzabo/Test/Utils.pm. - Added intermediate table and row classes for MethodMaker created classes, to provide a central point for adding new methods to table and row objects. Based on a patch from Ken Williams. - Support for "self-linking" tables in Alzabo::MethodMake
ANNOUNCE: Alzabo 0.79_03
0.79_03 October 18, 2003 ENHANCEMENTS: - Many doc rewrites and updates. - Documented row state classes. - Added back the no_cache parameter to avoid caching one or more rows. - Moved the relevant documentation from Alzabo::Runtime::PotentialRow into Alzabo::Runtime::Row. BUG FIXES: - Fixed the NAME portion of the Alzabo::MySQL and Alzabo::PostgreSQL POD files so that search.cpan.org doesn't think Alzabo::MySQL is the Alzabo.pm file. Reported by Darren Duncan. - The 12-rev_engineer_pg_fk.t test would try to load DBD::Pg even if you weren't using Postgres, which would cause the test file to die if DBD::Pg wasn't installed. Reported by Jost's smokehouse. - More documentation updates to remove outdated information. - Split out the documentation in Alzabo.pm into Alzabo::Intro and Alzabo::Design. - Added a FAQ from a question on the mailing list. Suggested by Terrence Brannon. - Eliminated a circular reference between tables created via the Alzabo::Runtime::Table->alias() method, and the columns those alias tables contain. This required the use of weak references. NOTE: Alzabo regular tables and columns have circular references to each other, but this normally isn't a problem because you generally want to keep a whole schema around all the time anyway. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: Alzabo 0.79_02
Another beta before 0.80. I'm still looking for feedback on the docs. Special thanks to Kineticode for funding some of the development done for this release. 0.79_02 October 17, 2003 ENHANCEMENTS: - Added support for table attributes like MySQL's "TYPE = ..." or Postgres's "WITH OIDS". - Added support for functional indexes in Postgres, like "LOWER(some_col)". Funded by Kineticode, LLC for Bricolage 2.0. - Added column/table constraint/check reverse engineering for Postgres. Funded by Kineticode, LLC for Bricolage 2.0. - The SQL generated for Postgres schemas now includes foreign key constraints. - Added a new method to Alzabo::Runtime::Schema, prefetch_none(). - Added a new method to Alzabo::Table, has_index(). - Documented Alzabo::Runtime::UniqueRowCache. - The definitions of the is_character and is_blob column methods have been clarified. Note that these definitions have changed from the previous, undefined behavior. - When a 1..1 or 1..n foreign key is added to a table, a unique index is created on the columns involved in the foreign key, unless those columns are part of the tables primary key. BUG FIXES: - Fixed a problem in the Makefile.PL which would cause it to fail even if you had Module::Build installed. Reported by Ken Williams. - Fixed (really, this time, I hope) a problem where the user-provided connection parameters were not respected in the 01-driver.t tests. Reported by Ken Williams. - FK reverse engineering for Postgres sometimes got the cardinality of the relationship wrong, making it 1..1 when it should be 1..n. This should be much improved in this release, though it may still have bugs. - Removed references to the old caching code in various spots. - Fixed handling case_sensitive parameter to Alzabo::Column->has_attribute(). BACKWARDS INCOMPATIBILITIES: - When you load a runtime schema, it now calls "$self->prefetch_all_but_blobs" in order to turn on pre-fetching by default, since for the vast majority of users, this is a huge performance improvement. The new prefetch_none() method can be used to turn off all prefetching. - The is_character column method now returns true for any text type column, regardless of size. - The is_blob column method now returns true only for columns that are defined to hold binary data. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
ANNOUNCE: Alzabo 0.79_01
This is a dev release for the hopefully soon 0.80 release. There's been a _lot_ of changes, so if people could test this and report back I'd be very grateful. There's also some features I might try to add before 0.80, notably table update & delete, but those don't seem that urgent. I'd also appreciate suggestions on how to improve the docs. I get the impression that lots of people find the docs a bit overwhelming and/or unclear, so pointers to specific spots that need work or suggestions on new pieces to add would be great. Special thanks go to Ilya Martynov and Ken Williams, both of whom contributed quite a bit to this release. Ilya contributed a monster refactoring patch for the row class, and Ken contributed many smaller patches to improve various aspects of Alzabo, notable MethodMaker and Postgres support. 0.79_01 ENHANCEMENTS: - Distribution is now signed with Module::Signature. - Lots of refactoring of the row object internals to simplify the code. Implemented by Ilya Martynov. - The testing code has been cleaned up quite a bit, and all of the utility functions used in the tests have been consolidated in t/lib/Alzabo/Test/Utils.pm. - Added intermediate table and row classes for MethodMaker created classes, to provide a central point for adding new methods to table and row objects. Based on a patch from Ken Williams. - Support for "self-linking" tables in Alzabo::MethodMaker, a linking table which connects a table to itself in an n..n relationship. Implemented by Ken Williams. - Added rdbms_version method to driver classes. Implemented by Ken Williams. - Added Alzabo::Create::Schema->is_saved() method. - Foreign keys are now reverse engineered for Postgres 7.3+. Implemented by Ken Williams. - Don't try to include dropped columns when reverse engineering Postgres 7.3+. Implemented by Ken Williams. - Do a better job of detecting SERIAL type columns when reverse engineering Postgres schemas. Based on a patch from Ken Williams. - Treat Postgres data types SERIAL4, SERIAL8, BIGSERIAL, and BIGINT as valid types. Implemented by Josh Jore. - NotNullable exception now include the table and schema name. Based on a patch from Ken Williams. - Primary keys are updateable. - Debugging output from Alzabo::MethodMaker is clearer about what methods are being made. Implemented by Ken Williams. - Alzabo::MethodMaker will now create foreign key methods when two tables have multiple relationships, as long as the name generation callback returns different names for each of them. Implemented by Ken Williams. - A join parameter can now specify an outer join with a single array reference, such as: [ left_outer_join => $table_A, $table_B ] Previously, this could only be done as a double array reference, like: [ [ left_outer_join => $table_A, $table_B ] ] - Various doc fixes and rewriting, most notably in Alzabo.pm. BUG FIXES: - A join using multiple aliased tables would fail with an error message like "Cannot use column (Foo.bar_id) in select unless its table is included in the FROM clause". - Remove the long-ago deprecated next_row() and next_rows() methods. - Postgres 7.3 allows identifiers to be up to 63 characters. This broke the code that handled sequenced columns for Postgres. Patch by Josh Jore. - If you tried to create a relationship between two tables, and the "table_to" table already had a column of the same name as the "column_from" column, then Alzabo died with an error. Reported by Ping Liang. - If you had previously installed Alzabo, and then provided a new Alzabo root directory or a new directory for the Mason components, this was not respected during the installation process. - Alzabo's referential integrity checks will no longer complain if you attempt to set a foreign key column to NULL. Previously it would throw an exception if the column was part of the dependent table in a foreign key relationship. Now, it just assumes you really meant to allow the column to be NULLable. - The schema class's load_from_file() method now blesses the loaded schema into the calling class. So if you use MethodMaker to generate classes, and then call My::Schema->load_from_file, it should always return an object blessed into the My::Schema class. Reported by Ken Williams. - When checking for the MySQL variable sql_mode, the value may be simply '' as opposed to 0. Patch by Andrew Baumhauer. BACKWARDS INCOMPATIBILITIES: - Alzabo now requires at least Perl 5.6.0 (5.6.1+ recommended). - The old caching system has been removed, as it had way too much overhead. There is a new, much simpler caching system provided by the Alzabo::UniqueRowCache module. - The Alzabo::Runtime::Table->row_by_pk() method no longer dies if it cannot find a matching row. Instead it simply returns false. - Some deprecated MethodMaker options were removed: insert, update, lookup_table - The Alzabo::Runtime::Row->delete() method now works for potential rows. -dave /*=== House
ANNOUNCE: Alzabo 0.73
Since there seem to be a few persistent bugs (particularly one that's new with Perl 5.8+), I'm release 0.73 as a bug fix release. I'm still working 0.80, which will have many more feature additions, and bug fixes, but hopefully this release will at least let people install Alzabo under Perl 5.8.0. It also fixes some bugs in how Alzabo interacted with newer versions of MySQL and Postgres. 0.73 October 5, 2003 BACKWARDS INCOMPATIBILITIES: - This release no longer includes the Mason schema creation GUI. It can be installed separately via the Alzabo::GUI::Mason package. BUG FIXES: - Fixed a bug in Alzabo::Create::Schema that only seems to be triggered by newer Perls. The symptom was an error like "Alzabo does not support the 'MySQL' RDBMS" when trying to create a new schema. - Fixed a warning in Alzabo::RDBMSRules. - The 01-driver.t test ignored any user-supplied RDBMS connection parameters. Reported by Barry Hoggard. - Newer versions of MySQL may return quoted table names, which broke reverse engineering. - Added a quick and nasty hack to remove the schema name from table names when reverse engineering Postgres schemas. - Reverse engineering of indexes for MySQL 4.0+ was broken. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
RE: Null terminated datetimes from SQL Server with DBD::ODBC
On Sat, 13 Sep 2003, Jeff Urlwin wrote: > I'd *highly* recommend installing the latest MDAC (2.7?) from Microsoft on > both the server and the client (security reasons for the server and correct > working queries on the client. If that still shows the problem, let me > know. I don't see it here. If you do see it, send me a small example that > reproduces it. We now have MDAC 2.8 on both ends (client & server) but we still see the problem. Unfortunately, I can't give you a simple recipe because I'm accessing the database entirely through stored procedures which I have no control over (welcome to my hell). It basically seems to happen whenever a stored procedure returns non-character data, as we've seen it for both integer & datetime types. Another weird thing is that if the stored procedure declares a return type to be BIGINT I get something back like "201,123,456,789.00\0x00", so it is somehow being _formatted_ somewhere. I'm guessing that this isn't something DBD::ODBC itself is doing, but no one can figure out where it could be happening. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Null terminated datetimes from SQL Server with DBD::ODBC
DBD::ODBC 1.06, DBI 1.37, SQL Server 2000, whatever ODBC drivers come with Win 2000 (SP3) (probably 2000.81.9030.04) Whenever datetimes are returned from a SQL statement, they end up looking something like: 3/3/2020 12:00:00 A\0 Anyone have any idea why this would happen? Integer and varchar fields seem to be fine, though. -dave /*=== House Absolute Consulting www.houseabsolute.com ===*/
Re: ANNOUNCE: DBD::Pg 1.20
I found a bug in the ->tables method. It includes all the system tables. A patch is at the bottom of the message. The SQL was correct in 1.13 so I'm not sure how this happened. There's also no real test of this method in the test suite, other than testing to make sure that calling it doesn't die. But you need to test that it returns the right thing too ;) I'd like to offer a test patch but I don't know exactly what you'd expect to find in the schema during testing. --- Pg.pm.old 2002-11-29 13:38:45.0 -0600 +++ Pg.pm 2002-11-29 13:38:18.0 -0600 @@ -531,6 +531,7 @@ select relname AS \"TABLE_NAME\" from pg_class where relkind = 'r' +andrelname !~ '^pg_' andrelname !~ '^xin[vx][0-9]+' order by 1 ") or return undef;
ANNOUNCE: Alzabo 0.70
Alzabo is a program and a module suite, with two core functions. Its first use is as a data modelling tool. Through either a schema creation interface or a perl program, you can create a set of schema, table, column, etc. objects to represent your data model. Alzabo is also capable of reverse engineering your data model from an existing system. Its second function is as an RDBMS to object mapping system. Once you have created a schema, you can use the Alzabo::Runtime::Table and Alzabo::Runtime::Row classes to access its data. These classes offer a high level interface to common operations such as SQL SELECT, INSERT, DELETE, and UPDATE commands. Please see http://www.alzabo.org/ for more info. Alzabo can be installed via the CPAN shell or downloaded from SourceForge. 0.70 November 21, 2002 ENHANCEMENTS: - The exception thrown when you attempt to set a non-nullable column to NULL is now an Alzabo::Exception::NotNullable exception, instead of an Alzabo::Exception::Params exception. In the interests of backwards compatibility, the former is a subclass of the latter. - Improved debugging options. See the new Alzabo::Debug module for details. BUG FIXES: - Fixed Alzabo::Table->primary_key, which would die when no primary key existed and it was called in an scalar context. In an array context, all the columns in the table were returned. Reported by Eric Prestemon. - Alzabo::ObjectCache::Sync::RDBMS created a table that it would later consider incorrect. This made this module unusable. - Alzabo::ObjectCache::Sync::RDBMS caused weird random errors when used with MySQL's InnoDB tables. - In the schema creator, the link to the graph page, and the link _on_ the graph page to the image, were both broken. - Alzabo was allowing you to rename a column to a name of an existing column in a table. Similarly, a table could be renamed to the same name as an existing table. Doing this could trash a schema. - Alzabo::Runtime::Table->one_row would return undef if no row was found, which in a list context evaluated to a true value. - Allow no_cache option when calling Alzabo::Runtime::Schema->join. - When displaying SQL, the schema creator now makes sure to HTML-escape it, because it's possible to have HTML in there (in a default, most likely). - The "children" method generated by Alzabo::MethodMaker did not allow you to add additional where clause constraints to the query.
Re: DBD::MySQL and 5.8
On 29 Sep 2002, Randal L. Schwartz wrote: > I got a casual (in-person) report last night from a user at a > conference I was attending that Perl 5.8.0 appeared to be incompatible > with DBD::MySQL. Now, I couldn't personally confirm or deny this, > since I use Pg exclusively now. Does anyone have anything > authoritative I can give back to the user if I bump into her today? I've been using recently with 5.8.0 (thread-enabled build, even) with no problems. -dave /*== www.urth.org we await the New Sun ==*/
ANNOUNCE: Alzabo 0.69
What, almost two months between releases?! I must be slowing down. Vacations will do that to you. This release corrects a rather nasty bug in the schema creation side of Alzabo, as well as a number of other bugs. Alzabo is a program and a module suite, with two core functions. Its first use is as a data modelling tool. Through either a schema creation interface or a perl program, you can create a set of schema, table, column, etc. objects to represent your data model. Alzabo is also capable of reverse engineering your data model from an existing system. Its second function is as an RDBMS to object mapping system. Once you have created a schema, you can use the Alzabo::Runtime::Table and Alzabo::Runtime::Row classes to access its data. These classes offer a high level interface to common operations such as SQL SELECT, INSERT, DELETE, and UPDATE commands. Please see http://www.alzabo.org/ for more info. Alzabo can be installed via the CPAN shell or downloaded from SourceForge. 0.69 September 19, 2002 ENHANCEMENTS: - Add count method to Alzabo::DriverStatement objects. BUG FIXES: ** - A particularly nasty bug sometimes manifested itself when removing a foreign key. This bug caused the deletion of all foreign keys involving the _corresponding_ column(s) in the foreign table. Needless to say, this could make a big mess. - A join that included a where clause with an 'OR' generated improper SQL. Reported by Ilya Martynov. - Calling the Alzabo::Runtime::JoinCursor->next_as_hash method when the query involved an outer join could cause a runtime error. - In where clause specifications, 'and' and 'or' were only being allowed in lower-case. They are now allowed in any case. - Aliases did not work in outer joins. This has been fixed. - Using outer joins was a bit fragile, in that the order of the outer join in the context of the other joins could cause Alzabo to generate incorrect SQL. Now outer joins should work no matter what. - A couple links in the schema creator had a hardcoded ".mhtml" extension, as opposed to using the value of Alzabo::Config::mason_extension(). Patch by Scott Lanning.
ANNOUNCE: Alzabo 0.67
[ Gah, the installer in 0.66 was a bit broken. This release fixes it. ] Alzabo is a program and a module suite, with two core functions. Its first use is as a data modelling tool. Through either a schema creation interface or a perl program, you can create a set of schema, table, column, etc. objects to represent your data model. Alzabo is also capable of reverse engineering your data model from an existing system. Its second function is as an RDBMS to object mapping system. Once you have created a schema, you can use the Alzabo::Runtime::Table and Alzabo::Runtime::Row classes to access its data. These classes offer a high level interface to common operations such as SQL SELECT, INSERT, DELETE, and UPDATE commands. Please see http://www.alzabo.org/ for more info. Alzabo can be installed via the CPAN shell or downloaded from SourceForge. 0.67 June 6, 2002 BUG FIXES: - There were some broken bits in the installation code in 0.66. These are now fixed. 0.66 June 6, 2002 ENHANCEMENTS: - It is now possible to retrieve auto-generated documentation to go along with the methods generated by Alzabo::MethodMaker. See the "GENERATED DOCUMENTATION" section of the Alzabo::MethodMaker docs for more details. - Added documentation to all the components in mason/widgets. You can run perldoc on those files for more details. - Added a very ugly hack to work around a bug with Storable 2.00 - 2.03 and a Perl < 5.8.0. - It is now possible to install Alzabo without defining an Alzabo root directory. This means you will have to set this by calling Alzabo::Config::root_dir() every time you load Alzabo. An attempt to load a schema without first defining the root_dir will throw an exception. Based on a patch from Ilya Martynov. BUG FIXES: - Allow UNIQUE as a column attribute for Postgres. Reported by Dan Martinez. - Add DISTINCT back as an exportable function from the SQLMaker subclasses. It may be useful when calling ->select and ->function. - Fixed a bug that prevented things from being deleted from the cache storage. - Fixed a variety of problems related to handling Postgres tables and columns with mixed or upper case names. This included a bug that prevented them from being reverse engineered properly. Reported by Terrence Brannon. - Fixed a bug when altering a Postgres column name that caused Alzabo to generate incorrect syncing SQL. - Make the test suite play nice with the latest Test::* modules. The 03-runtime.t tests were aborting because I feature I had been using in earlier versions of Test::More was removed. - Alzabo::MethodMaker will die properly if given a non-existent schema name. Suggested by Ilya Martynov. - If you added a sequenced primary key to a table with MySQL, Alzabo did not generate all of the SQL necessary to change the table. Reported by Ilya Martynov. DEPRECATIONS: - The Alzabo::Schema start_transaction method has been renamed to begin_work. The finish_transaction method is now commit. The old names are deprecated.
ANNOUNCE: Alzabo 0.66
Alzabo is a program and a module suite, with two core functions. Its first use is as a data modelling tool. Through either a schema creation interface or a perl program, you can create a set of schema, table, column, etc. objects to represent your data model. Alzabo is also capable of reverse engineering your data model from an existing system. Its second function is as an RDBMS to object mapping system. Once you have created a schema, you can use the Alzabo::Runtime::Table and Alzabo::Runtime::Row classes to access its data. These classes offer a high level interface to common operations such as SQL SELECT, INSERT, DELETE, and UPDATE commands. Please see http://www.alzabo.org/ for more info. Alzabo can be installed via the CPAN shell or downloaded from SourceForge. 0.66 June 6, 2002 ENHANCEMENTS: - It is now possible to retrieve auto-generated documentation to go along with the methods generated by Alzabo::MethodMaker. See the "GENERATED DOCUMENTATION" section of the Alzabo::MethodMaker docs for more details. - Added documentation to all the components in mason/widgets. You can run perldoc on those files for more details. - Added a very ugly hack to work around a bug with Storable 2.00 - 2.03 and a Perl < 5.8.0. - It is now possible to install Alzabo without defining an Alzabo root directory. This means you will have to set this by calling Alzabo::Config::root_dir() every time you load Alzabo. An attempt to load a schema without first defining the root_dir will throw an exception. Based on a patch from Ilya Martynov. BUG FIXES: - Allow UNIQUE as a column attribute for Postgres. Reported by Dan Martinez. - Add DISTINCT back as an exportable function from the SQLMaker subclasses. It may be useful when calling ->select and ->function. - Fixed a bug that prevented things from being deleted from the cache storage. - Fixed a variety of problems related to handling Postgres tables and columns with mixed or upper case names. This included a bug that prevented them from being reverse engineered properly. Reported by Terrence Brannon. - Fixed a bug when altering a Postgres column name that caused Alzabo to generate incorrect syncing SQL. - Make the test suite play nice with the latest Test::* modules. The 03-runtime.t tests were aborting because I feature I had been using in earlier versions of Test::More was removed. - Alzabo::MethodMaker will die properly if given a non-existent schema name. Suggested by Ilya Martynov. - If you added a sequenced primary key to a table with MySQL, Alzabo did not generate all of the SQL necessary to change the table. Reported by Ilya Martynov. DEPRECATIONS: - The Alzabo::Schema start_transaction method has been renamed to begin_work. The finish_transaction method is now commit. The old names are deprecated.
Re: ANNOUNCE: DBI 1.25
On Thu, 6 Jun 2002, Tim Bunce wrote:
> =head2 Changes in DBI 1.25,5th June 2002
>
> Fixed $dbh->{Driver} and $sth->{Statement} for driver internals
> These are 'inner' handles as per behaviour prior to DBI 1.16.
Works for me. Thanks, Tim.
-dave
/*==
www.urth.org
we await the New Sun
==*/
$dbh->func broken with DBI 1.24 and DBD::mysql
It looks like something in DBI 1.24 broke $dbh->func.
If I try to call this:
$dbh->func( 'createdb', 'foo', 'admin' )
I get an array message about being unable to call func on an undef value
at DBD::mysql line 217.
sub admin {
my($dbh) = shift;
my($command) = shift;
my($dbname) = ($command eq 'createdb' || $command eq 'dropdb') ?
shift : '';
$dbh->{'Driver'}->func($dbh, $command, $dbname, '', '', '',
'_admin_internal');
}
Line 217 is the line above starting with $dbh->{'Driver'}->func
If I had to guess at what was broken I'd say it had to do with this change
from 1.16:
Fixed $dbh->{Driver} & $sth->{Database} to return 'outer' handles.
and then this change from 1.24:
Fixed reference loop causing a handle/memory leak
that was introduced in DBI 1.16.
I'm guessing these are related? I also noticed that this code in DBI.xs
(from 1.23):
case DBIt_DB:
/* pre-load Driver attribute */
hv_store((HV*)SvRV(h), "Driver", 6, newRV((SV*)DBIc_MY_H(parent_imp)), 0);
break;
is gone in 1.24. So just for yucks I added it back and that seemed to fix
the problem.
I don't know _why_ it fixed it, but it did.
-dave
/*==
www.urth.org
we await the New Sun
==*/
ANNOUNCE: Alzabo 0.65
Alzabo is a program and a module suite, with two core functions. Its first
use is as a data modelling tool. Through either a schema creation
interface or a perl program, you can create a set of schema, table,
column, etc. objects to represent your data model. Alzabo is also capable
of reverse engineering your data model from an existing system.
Its second function is as an RDBMS to object mapping system. Once you have
created a schema, you can use the Alzabo::Runtime::Table and
Alzabo::Runtime::Row classes to access its data. These classes offer a
high level interface to common operations such as SQL SELECT, INSERT,
DELETE, and UPDATE commands.
Please see http://www.alzabo.org/ for more info. You can also install
Alzabo via CPAN.
0.65 May 16, 2002
INCOMPATIBILITIES:
- Alzabo now uses the natively created Postgres sequence for SERIAL
columns. If you have existing Alzabo code with SERIAL columns that is
using the Alzabo-created sequence, then this release will break things
for you. One easy fix is to simply drop the existing Postgres-created
sequence and recreate it with a new starting number one higher than
the highest row already in existence. So if your hightest "foo_id"
value in the "Foo" table is 500, you would do this:
DROP SEQUENCE foo_foo_id_seq;
CREATE SEQUENCE foo_foo_id_seq START 501;
- The Alzabo::Table->primary_key method is now context-sensitive,
returning a single column object in scalar context.
- The data browser is no longer installed, until such time as I can
rewrite it to be more useful.
DEPRECATIONS:
- The Alzabo::Create::Schema->add_relation method has been renamed as
Alzabo::Create::Schema->add_relationship.
ENHANCEMENTS:
- Check out the mason/widgets directory for some handy widgets that
can help integrate Mason and Alzabo in useful ways. These aren't
really well-documented yet but may be useful for playing with. More
widgets will be included in future releases (I hope).
- When creating a relationship between tables in the schema creator,
you can now let Alzabo figure out which columns to use instead of
choosing them yourself. For most relationships, Alzabo will simply do
the right thing, adding a column to one of the tables as needed.
- The problems running the tests with Postgres should now be fixed.
- Fix stupid and inefficient internal handling of "SELECT DISTINCT"
queries. Now Alzabo simply lets the database handle this, the way it
should have in the first place.
- The Alzabo::Runtime::Schema and Alzabo::Runtime::Table ->function
and ->select methods now allow you to select scalars so you can do
things like SELECT 1 FROM Foo WHERE ... in order to test for the
existence of a row.
- Added Alzabo::Table->primary_key_size method, which indicates how
many columns participate in the table's primary key.
- Added Alzabo::Runtime::Schema->row_count. Suggested by Daniel
Gaspani.
- Alzabo now detects older versions of schemas and transparently
updates them. This will work for all schemas created with version
0.55 or later.
See the section titled "Backwards Compability" in Alzabo.pm for more
details.
- Added comment attribute for tables, columns, and foreign keys.
- Add VARBIT and TIMESTAMPTZ as legal types for Postgres.
- Handle SERIAL columns in Postgres better. Use the sequence Postgres
creates for the columns rather than making our own and just insert
undef into new rows for that column.
BUG FIXES:
- Adding a column that is not-nullable or has a default to a table
under Postgres was causing an error with Postgres 7.2.1. It seems
likely that with earlier versions of Postgres, this was simply failing
silently. Patch by Daniel Gaspani.
- Fixed buggy handling of joins that had a table with a multi-column
primary key as the "distinct" parameter.
- Calling the Alzabo::Runtime::Schema->join method with no 'select'
parameter and a 'join' parameter that was an array reference of array
references would fail.
- Avoid an uninit value in Alzabo::MethodMaker. Reported by Daniel
Gaspani.
- If you created a cursor inside an eval{} block, the cursor contained
an object whose DESTROY method would overwrite $@ as it went out of
scope when the eval block exited. This could basically make it look
like an exception had disappeared. Thanks to Brad Bowman for an
excellent bug report.
- Loading a schema failed in taint mode. This was reported ages ago
by Raul Nohea Goodness and dropped on the floor by me. My bad.
- The schema creator's exception handling was a little bit buggered
up when handling Alzabo::Exception::Driver exceptions.
Re: Using \COPY in DBI:Pg and DBIx::Recordset
On Mon, 1 Apr 2002, Marcus Claesson wrote: > > Why are you trying to put a backslash in there. DBI is not the psql tool! > > Get rid of the backslash. > > The reason for using \COPY here is that you otherwise have to be superuser to > copy (with the plain COPY) the data into a created table. I'm building a web > interface where the user will copy his data into the db himself and thus > obviously cannot be the superuser. > Of course, that can be done with INSERT too but a COPY is much faster. There is no "\copy" in the SQL docs, is there? The fact that there happens to be a command you can use in psql called "\copy" does not mean that there is an equivalent SQL statement. -dave /*== www.urth.org we await the New Sun ==*/
Re: Using \COPY in DBI:Pg and DBIx::Recordset
On Thu, 28 Mar 2002, Marcus Claesson wrote:
> > perl -e '$a= "\Copy"; print "$a\n";' > Copy
>
> You're right about that perl loses the '\'.
> But when I try to escape the backslash by typing
> $dbh->do("\\COPY table FROM 'file.dat'");
> I get this message:
> DBD::Pg::db do failed: ERROR: parser: parse error at or near "\" at
> /var/www/cgi-bin/marcus/ma_merge2.pl line 55.
>
> What would be the way to get around this do you think?
Why are you trying to put a backslash in there. DBI is not the psql tool!
Get rid of the backslash.
-dave
/*==
www.urth.org
we await the New Sun
==*/
Re: DBD::Pg and RowCacheSize?
On 18 Feb 2002, Jeff Boes wrote: > Is it true that RowCacheSize has no effect with the DBD::Pg driver? The > DBD::Pg doc just says that it's "Implemented by DBI, not used by > driver", which implies that DBI actually does something by default. I believe the "Implemented by DBI" phrase simply means it is part of the official DBI driver spec. However, a driver doesn't actually have to do anything with it. What it _could_ do (maybe) is use a Postgres cursor to implement it, which would be slick. I'm sure Edmund would welcome a patch ;) -dave /*== www.urth.org we await the New Sun ==*/
ANNOUNCE: Alzabo 0.63
Alzabo is a program and a module suite, with two core functions. Its first
use is as a data modelling tool. Through either a schema creation
interface or a perl program, you can create a set of schema, table,
column, etc. objects to represent your data model. Alzabo is also capable
of reverse engineering your data model from an existing system.
Its second function is as an RDBMS to object mapping system. Once you have
created a schema, you can use the Alzabo::Runtime::Table and
Alzabo::Runtime::Row classes to access its data. These classes offer a
high level interface to common operations such as SQL SELECT, INSERT,
DELETE, and UPDATE commands.
Please see http://alzabo.sourceforge.net/ for more info. You can also
install Alzabo via CPAN.
0.63
ENHANCEMENTS:
- Calling Alzabo::Runtime::Row->select or
Alzabo::Runtime::Row->select_hash with no arguments returns the values
for all of the columns in the table. Suggested by Jeremy R. Semeiks.
- The Alzabo::Runtime::Row->id method has been renamed to id_as_string
for the benefit of those crazy people who like to use "id" as a column
name and want Alzabo::MethodMaker to be able to create such a method.
Suggested by Alexei Barantsev.
- Changed the Alzabo::Create::Schema->sync_backend method so that if
there was no corresponding schema in the RDBMS, then it will
instantiate a new schema instead of just blowing up. Similarly, the
sync_backend_sql method will just return the SQL necessary to create
the schema from scratch.
BUG FIXES:
- Removing column attributes via the schema creator was broken.
Adding them could have caused errors but generally worked.
- If you changed a column from non-sequenced to sequenced, the SQL
"diff" was not reflecting this.
- Revert a previous change to MySQL reverse engineering. Now default
for numeric columns that are not 0 or 0.00 are used instead of being
ignored. The fact that MySQL has 'default defaults' _really_ screws
things up. Bad MySQL!
- A query that ended with a subgroup could not be followed with an
order by or group by clause. Bug report and test case submitted by
Ilya Martynov.
- Nested subgroups in where clauses (like where => [ '(', '(', )
were not being allowed. Bug report and test case submitted by Ilya
Martynov.
- Alzabo::MethodMaker would overwrite methods in the
Alzabo::Runtime::Row/CachedRow/PotentialRow classes. This has been
fixed. Reported by Alexei Barantsev.
- Allow order by clause to contain only a SQL function to allow things
like "SELECT foo FROM Bar ORDER BY RAND()", which works with MySQL.
Re: Again NULL Values
On Thu, 14 Feb 2002, Bryan Tolka wrote:
> if ($ip ne $oldip){
> $sth = $dbh->prepare("update ipmgt set
> ip = '$oldip'
> hw = ,
> dnsName = ,
Um, you can't just leave it empty!
Use bound values (read the DBI docs for info on placeholders). This is
much easier anyway. And read the MySQL docs on SQL since you're obviously
not terribly familiar with SQL (an introductory SQL book wouldn't hurt
either).
-davet
/*==
www.urth.org
we await the New Sun
==*/
Re: Anyone using $dbh->{Handlers} attribute ?
On Wed, 6 Feb 2002, Tim Bunce wrote:
> How does this sound:
>
> =item C (code ref, inherited) I
>
> This attribute can be used to provide your own alternative behaviour
> in case of errors. If set to a reference to a subroutine then that
> subroutine is called when an error is detected (at the same point that
> C and C are handled).
>
> The subroutine is called with three parameters: the error message
> string that C and C would use,
> the DBI handle being used, and the first value being returned by
> the method that failed (typically undef).
>
> If the subroutine returns a false value then the C
> and/or C attributes are checked and acted upon as normal.
This sounds great. Right now Alzabo wraps all its DBI calls inside eval
{} (RaiseError is on) and then checks $@ and throws its own exception if
$@ is true. Being able to set this HandleError attribute when the handle
is created will reduce the amount of code in my wrapper by a decent
amount. Sweet!
-dave
/*==
www.urth.org
we await the New Sun
==*/
ANNOUNCE: Alzabo 0.62
Alzabo is a program and a module suite, with two core functions. Its first
use is as a data modelling tool. Through either a schema creation
interface or a perl program, you can create a set of schema, table,
column, etc. objects to represent your data model. Alzabo is also capable
of reverse engineering your data model from an existing system.
Its second function is as an RDBMS to object mapping system. Once you have
created a schema, you can use the Alzabo::Runtime::Table and
Alzabo::Runtime::Row classes to access its data. These classes offer a
high level interface to common operations such as SQL SELECT, INSERT,
DELETE, and UPDATE commands.
Please see http://alzabo.sourceforge.net/ for more info. You can also
install Alzabo via CPAN.
0.62
ENHANCEMENTS:
- Add support for IFNULL, NULLIF, and IF for MySQL.
- Document that Alzabo supports COALESCE and NULLIF for Postgres.
- Added Alzabo::ObjectCache::Sync::Mmap which uses Cache::Mmap. This
is just slightly slower than using SDBM_File.
- New table alias feature for making queries that join against a table
more than once. An example:
my $foo_alias = $foo_tab->alias;
my $cursor = $schema->join( select => $foo_tab,
tables => [ $foo_tab, $bar_tab, $foo_alias ],
where => [ [ $bar_tab->column('baz'), '=', 10 ],
[ $foo_alias->column('quux'), '=', 100 ] ],
order_by => $foo_alias->column('briz') );
In this query, we want to get all the entries in the foo table based
on a join between foo and bar with certain conditions. However, we
want to order the results by a _different_ criteria than that used for
the join. This doesn't necessarily happen often, but when it does its
nice to be able to do it. In SQL, this query would look something
like this:
SELECT foo.foo_id
FROM foo, bar, foo as foo1
WHERE foo.foo_id = bar.foo_id
AND bar.foo_id = foo1.foo_id
AND bar.baz = 10
AND foo1.quux = 100
ORDER BY foo1.quux
FEATURE REMOVAL:
- It is no longer possible to pass sorting specifications ('ASC' or
'DESC') as part of the group_by parameter. This was only supported by
MySQL and it was broken in MySQL until 3.23.47 anyway. Its weird and
non-standard. Just use order_by instead.
BUG FIXES:
- If prefetch wasn't set, all the rows in the table were being
pre-fetched.
- The newest Test::More (0.40) uses eval{} inside its isa_ok()
function. The test suite was passing $@ directly into isa_ok() and it
would then get reset by the eval{} in the isa_ok() function. This has
been fixed by copying $@ into another variable before passing it into
isa_ok(). Apparently, Test::More 0.41 will fix this as well.
- Make Alzabo::ObjectCache::Store::RDBMS and
Alzabo::ObjectCache::Sync::RDBMS play nice with Postgres. Pg aborts
transactions when there are errors like an attempt to insert a
duplicate inside a transaction. These module would just try to insert
potentially duplicate rows and ignore the error. Now Pg is handled
specially.
- If you told the installer that you didn't want to run any tests with
a live database, there would be errors when it tried to run
03-runtime.t. Now it just skips it.
- Alzabo includes a script called 'pod_merge.pl' that is run before
installing its modules. This script merges POD from a parent class
into a child class (like from Alzabo::Table into
Alzabo::Create::Table) in order to get all the relevant documentation
in one place. The way the Makefile.PL ran this script was not working
for some people, and in addition, did not end up putting the merged
documentation into the generated man pages. This release includes a
patch from Ilya Martynov that fixes both of these problems.
Re: PostgreSQL book
On Fri, 11 Jan 2002, Philip Molter wrote: > The only downside you're going to find are the down/upsides of > switching from MySQL to PostgreSQL. The DBI interface won't change > for you. My personal experience between the two databases is that > MySQL is easier to manage, easier to work with, and enjoys more > active support from the Perl development community. With MySQL's > InnoDB tables, there's really not much that PostgreSQL has over > MySQL except for very advanced, mostly proprietary extensions (with > the exception of triggers, which are coming). In everything I've > coded, MySQL beats PostgreSQL hands-down for speed when both are > configured properly. Well, there are some neat features. The table inheritance bits (really sub- and super-types) is potentially really useful, and all RDBMS's _should_ support this because it solves some rather common problems. Of course, I haven't used it myself (mostly because I haven't gotten Alzabo around to supporting it). Postgres also has views, which MySQL doesn't have. I also don't know if InnoDB+MySQL supports all constraints, or just referential integrity contraints. Also, MySQL's query optimizer is _really_ bad when it comes to complex where clauses. For example, a select like this: SELECT foo FROM Foo where indexed_col_1 = 'x' OR indexed_col_2 = 'y' will not use either index. That can be really bad. >From what I've heard, the Postgres optimizer is quite a bit better. Also, I'd be curious to see a speed comparison across a wide range of operations (simple & complex selects, insert, update, delete) between Postgres and InnoDB+MySQL. Obviously, MySQL+MyISAM is faster. But I'd be surprised if InnoDB was significantly faster than Postgres. -dave /*== www.urth.org we await the New Sun ==*/
Re: Important: Subclassing and Merging DBIx::AnyDBD into the DBI
On Fri, 4 Jan 2002, Simon Oliver wrote: > What I like is the fact that it will be integrated into core DBI and promote > the use of this subclassing mechanism as a basis for writing cross-platform > code rather than each modules reinventing the wheel (c.f. Alzabo). Yep, I'm thinking that I'll convert Alzabo's driver modules over to using this once it exists. FWIW, much of what Alzabo does in terms of a per-RDBMS subclass is _way_ beyond what DBI exists for (things like knowing how to generate CREATE/DROP/ALTER SQL statements or what schema/table/column names are valid). That stuff is unlikely to move into a DBI subclass because its not DBI type stuff. -dave /*== www.urth.org we await the New Sun ==*/
ANNOUNCE: Alzabo 0.61
Alzabo is a program and a module suite, with two core functions. Its first
use is as a data modelling tool. Through either a schema creation
interface or a perl program, you can create a set of schema, table,
column, etc. objects to represent your data model. Alzabo is also capable
of reverse engineering your data model from an existing system.
Its second function is as an RDBMS to object mapping system. Once you have
created a schema, you can use the Alzabo::Runtime::Table and
Alzabo::Runtime::Row classes to access its data. These classes offer a
high level interface to common operations such as SQL SELECT, INSERT,
DELETE, and UPDATE commands.
Please see http://alzabo.sourceforge.net/ for more info. You can also
install Alzabo via CPAN.
0.61
ENHANCEMENTS:
- Improve documentation for new Alzabo::Create::Schema->sync_backend
method and note its caveats.
- It is now possible to use SQL functions as part of order_by clauses.
For example:
my $cursor = $schema->select( select => [ COUNT('*'), $id_col ],
tables => [ $foo_tab, $bar_tab ],
group_by => $id_col,
order_by => [ COUNT('*'), 'DESC' ] );
- Allow a call to Alzabo::Runtime::Table->insert without a values
parameter. This is potentially useful for tables where the primary
key is sequenced and the other columns have defaults or are NULLable.
Patch by Ilya Martynov.
BUG FIXES:
- A call to the schema class's select or function methods that had
both an order_by and group_by parameter would fail because it tried to
process the order by clause before the group by clause.
- When thawing potential row objects, Alzabo was trying to stick them
into the cache, which may have worked before but not now, and should
be avoided anyway.
- The parent and children methods created by Alzabo::MethodMaker were
incorrect (and unfortunately the tests of this feature were hosed
too).
- Add YEAR as exportable function from Alzabo::SQLMaker::MySQL.
- Fix definition of WEEK and YEARWEEK functions exported from
Alzabo::SQLMaker::MySQL to accept 1 or 2 parameters.
- A bug in the caching code was throwing an exception when attempting
to update objects that weren't expired. This only seemed to occur in
conjuction with the prefetch functionality. The caching code has been
simplified a bit and is hopefully now bug-free (I can dream, can't
I?).
- Make it possible to call Alzabo::Runtime::Schema->join with only one
table in the tables parameter. This is useful if you are constructing
your join at runtime and you don't know how many tables you'll end up
with.
- Where clauses that began with '(' were not working. Reported (with
a test suite patch) by Ilya Martynov.
- Where clauses that contained something like ( ')', 'and' (or 'or') )
were not working either.
- This file incorrectly thanked TJ Mather for separating out
Class::Factory::Util, but this was done by Terrence Brannon. Oops,
brain fart.
- Improve the recognition of more defaults that MySQL uses for column
lengths and defaults, in order to improve reverse engineering.
- Recognize defaults like 0 or '' for MySQL.
- Fix Alzabo::Create::Schema->sync_backend method.
Re: Suggested new module -- DBI::Wrapper or DBIx::Wrapper
On Mon, 10 Dec 2001, Matisse Enzer wrote: > DBI/Wrapper version 0.01 > > > DBI::Wrapper is a simple module that provides a high-level interface > to the Perl DBI module. The provided methods are for fetching > a single record (returns a hash-ref), many records (returns > an array-ref of hash-refs), and for executing a non-select statement > (returns a result code). There are a lot of tools that already provide wrappers around DBI. These include: Alzabo, DBIx::RecordSet, and Class::DBI all provide fairly high level RDBMS-OO mappers. Other lower-level wrappers include DBIx::Abstract, DBIx::Easy, DBIx::SearchBuilder, and EZDBI. There's really more than enough of these things at this point. Probably one of them already does most of the things yours does, so I'd suggest you find that one and offer the author patches for any features you think it might be missing. -dave /*== www.urth.org We await the New Sun ==*/
ANNOUNCE: Alzabo 0.60
Alzabo is a program and a module suite, with two core functions. Its first
use is as a data modelling tool. Through either a schema creation
interface or a perl program, you can create a set of schema, table,
column, etc. objects to represent your data model. Alzabo is also capable
of reverse engineering your data model from an existing system.
Its second function is as an RDBMS to object mapping system. Once you have
created a schema, you can use the Alzabo::Runtime::Table and
Alzabo::Runtime::Row classes to access its data. These classes offer a
high level interface to common operations such as SQL SELECT, INSERT,
DELETE, and UPDATE commands.
Please see http://alzabo.sourceforge.net/ for more info. You can also
install Alzabo via CPAN.
0.60
ENHANCEMENTS:
- When passing order_by specifications, it is now possible to do this:
order_by => [ $col1, $col2, 'DESC', $col3, 'ASC' ]
which allow for multiple levels of sorting as well as being much
simpler to remember.
- It is now possible to do something like
$table->select( select => [ 1, $column ] ... );
and have it work. In this case, every row returned by the cursor will
have 1 as its first element.
- Added Alzabo::MySQL and Alzabo::PostgreSQL POD pages. These pages
document how Alzabo does (or does not) support various RDBMS specific
features.
- Remove Alzabo::Util. Use Class::Factory::Util from CPAN instead.
Class::Factory::Util is a slight revision of Alzabo::Util that has
been separated from the Alzabo core code by TJ Mather. Thanks TJ.
- Add the ability to sync the RDBMS backend to the current state of
the Alzabo schema. This allows you to arbitrarily update the RDBMS
schema to match the current state of the Alzabo schema.
- Add support for SELECT and WHERE clauses that use MySQL's fulltext
search features.
- Add BIT and BIT VARYING as allowed types for Postgres.
BUG FIXES:
- Reverse engineering was not checking for fulltext indexes with
MySQL. These indexes were treated the same as other indexes.
- Make sure Alzabo::SQLMaker always handles stringification of
literals properly.
- Improve recognition of default column lengths under MySQL (and
ignore them). Also improve recognition of default defaults (like
'-00-00' for DATE columns) and ignore those.
- When using the BerkeleyDB module for object syncing or storage, the
Berkeley DB code itself creates a number of temporary files. These
will now be created in the same directory as the storage/syncing file
specified.
- Allow GROUP BY foo ASC/DESC for MySQL. The MySQL manual claims this
works. In my testing, it accepts the syntax but doesn't actually
respect the order requested. Of course, you can always add order by
clause with your group by and that seems to work just fine.
- Don't allow a GROUP BY clause to follow an ORDER BY clause. The
reverse is still allowed.
- MySQL: Allow fulltext indexes to include *text type columns without
specifying a prefix.
- Dropping a column that had an index on it would cause an error in
the generated SQL diff where Alzabo would drop the column and then try
to drop (the now non-existent) index. The fix is simply to drop the
indexes first.
- Make caching code work under Perl 5.00503.
- Make code warnings clean (I think) under Perl 5.00503;
DEPRECATIONS:
- The way order_by and group_by parameters are passed has changed a
bit. In particular, this form:
order_by => { columns => ..., sort => ... }
has been deprecated in favor of a simpler syntax.
Re: Problem with placeholders in DBD::Pg
On Mon, 26 Nov 2001, Todd Nemanich wrote: > 11\:16\:43', '2001-01-17 00\:00\:00', '2001-01-16', 'Phoned re\:mc and ^^ ^^ It thinks those are placeholders. The DBD::Pg module parses placeholders itself and replaces them before sending the SQL to the RDBMS. Apparently the parsing isn't quite as smart as it should be ;) Anyway, I'd suggest that you really _should use placeholders because the above is a mess. The DBD::Pg modules handles simple ? placeholders correctly and will automatically quote all your values if needed. -dave /*== www.urth.org We await the New Sun ==*/
ANNOUNCE: Alzabo 0.59
Alzabo is a program and a module suite, with two core functions. Its first use is as a data modelling tool. Through either a schema creation interface or a perl program, you can create a set of schema, table, column, etc. objects to represent your data model. Alzabo is also capable of reverse engineering your data model from an existing system. Its second function is as an RDBMS to object mapping system. Once you have created a schema, you can use the Alzabo::Runtime::Table and Alzabo::Runtime::Row classes to access its data. These classes offer a high level interface to common operations such as SQL SELECT, INSERT, DELETE, and UPDATE commands. Please see http://alzabo.sourceforge.net/ for more info. You can also install Alzabo via CPAN. I think I somehow forgot to announce 0.58 so here is the changelog for 0.58 and 0.59 0.59 ENHANCEMENTS: - Got rid of the post_select_hash hook and combined it with post_select, which now receives a hash reference. Suggested by Ilya Martynov. - Run all hooks inside Alzabo::Schema->run_in_transaction method to ensure database integrity in cases where your hooks might update/delete/insert data. Suggested by Ilya Martynov. - Added new Alzabo::Runtime::Table->select method. This is just like the existing ->function method, but returns a cursor instead of the entire result set. - Added a 'limit' parameter to the ->function method (also works for the ->select method). - Added new Alzabo::Runtime::Schema->select method. This is like the method of the same name in the table class but it allows for joins. - Added new potential rows, which are objects with (largely) the same interface as regular rows, but which are not (yet) inserted into the database. They are created via the new Alzabo::Runtime::Table->potential_row method. Thanks to Ilya Martynov for suggestions and code for this feature. - Added Alzabo::Runtime::Row->schema method. Suggested by Ilya Martynov. - Made it possible to use Storable to freeze and thaw any type of row object. Previously, this would have worked but would have serialized basically every single Alzabo object in memory (whee!). Patch by Ilya Martynov. - Make Alzabo::Schema->run_in_transaction preserve scalar/array context and return whatever was returned by the wrapped code. BUG FIXES: - Did some review and cleanup of the exception handling code. There were some places where exceptions were being handled in an unsafe manner as well as some spots where exception objects should have been thrown that were just using die. - Ignore failure to rollback for MySQL when not using transactional table. - Alzabo was not handling the BETWEEN operator in where clauses properly. Patch by Eric Hillman. - Passing in something like this to rows_where: ( where => [ $col_foo, '=', 1, $col_bar, '=', 2 ] ) worked when it shouldn't. - Trying to do a select that involved a group by and a limit was not being allowed. INCOMPATIBILITIES: - Got rid of the post_select_hash hook and combined it with post_select, which now receives a hash reference. -- 0.58 ENHANCEMENTS: - Added new insert_hooks, update_hooks, select_hooks, and delete_hooks options to Alzabo::MethodMaker. Suggested by Ilya Martynov. - Moved all the important document for the object caching system into Alzabo::ObjectCache, including the import options for all of the various modules. - Added Alzabo::ObjectCache::Sync::RDBMS & Alzabo::ObjectCache::Store::RDBMS. The former finally allows synchronization of multiple processes across multiple machines! - Add Alzabo::Schema->has_table and Alzabo::Table->has_column methods. - Make BYTEA a legal column type for postgres. This is treated as a blob type. BUG FIXES: - The way cardinality and dependency was being represented in the schema graphs was sometimes backward and sometimes just broken. - Fixed Alzabo::ObjectCache::Store::BerkeleyDB->clear, which was not actually doing anything. Added tests that catch this. - The lookup_tables option, which was deprecated in 0.57, was not being allowed at all. - Calls to select_hash on cached rows were not going through the cache checking routines, possibly returning expired data. Added tests for this. - Eliminate race condition in Alzabo::ObjectCache::Sync::BerkeleyDB. - The Alzabo::Runtime::Row->rows_by_foreign_key method wasn't doing quite what it said. In cases where there was a 1..1 or n..1 relationship to columns that were not the table's primary key, a cursor would be returned instead of a single row. Reported by Ilya Martynov. - Alzabo::MethoMaker could generate 'subroutine foo redefined' warnings . Reported by Ilya Martynov. - Fixed clear method for all Alzabo::ObjectCache::Store::* modules. DEPRECATIONS: - The insert and update options for Alzabo::MethodMaker have been deprecated. They have been replaced by the new insert_hooks and update_hooks options, along with new select_hooks and delete_hooks
Re: Alzabo
On Fri, 19 Oct 2001, David Kirol wrote: > I want to explore the Alzabo data modeling tool but I cannot find any > tutorial or how to on the web. Can anyone point me in the right direction? Someone also mentioned the Linux Journal article, which is a good start. Also, check out the docs at http://alzabo.sourceforge.net/docs/. Then click the first link (just "Alzabo") in the list. The page there has a list of things you should read first. However, the data modelling web interface itself isn't well documented (but its really self-explanatory). The docs _will_ give you ideas on how to create a data model via a script (which I don't like doing, which is why I wrote the web interface in the first place!). There are a _lot_ of docs, which is both good and bad. It takes while to get through everything but at least its all there. If you have any questions send them to the alzabo users list (http://lists.sourceforge.net/lists/listinfo/alzabo-general) -dave /*== www.urth.org We await the New Sun ==*/
ANNOUNCE: Alzabo 0.57
Alzabo is a program and a module suite, with two core functions. Its first use is as a data modelling tool. Through either a schema creation interface or a perl program, you can create a set of schema, table, column, etc. objects to represent your data model. Alzabo is also capable of reverse engineering your data model from an existing system. Its second function is as an RDBMS to object mapping system. Once you have created a schema, you can use the Alzabo::Runtime::Table and Alzabo::Runtime::Row classes to access its data. These classes offer a high level interface to common operations such as SQL SELECT, INSERT, DELETE, and UPDATE commands. Please see http://alzabo.sourceforge.net/ for more info. You can also install Alzabo via CPAN. 0.57 ENHANCEMENTS: - When MethodMaker creates 'row_column' methods, these are now get/set methods. - Added lookup_columns to MethodMaker option (like lookup_tables but more flexible). This replaces the now deprecated lookup_tables option. See DEPRECATIONS and INCOMPATIBILITIES for more details. - Added the ability to make any storage cache module an LRU. Simply pass an lru_size parameter to Alzabo::ObjectCache when using it and the storage module will be an LRU cache. - Documented Alzabo's referential integrity rules in Alzabo.pm (perldoc Alzabo). - Added section on optimizing memory usage to Alzabo::FAQ. - Alzabo::Runtime::Schema->join now takes a parameter called 'distinct'. This is useful in situations where you are joining between several tables but don't want rows back from all of them. In that case, it is possible that you could end up getting more duplicates than you need. This parameter can help you eliminate those. - Add the following Alzabo::Schema methods: start_transaction, rollback, finish_transaction, run_in_transaction. - If you have GraphViz installed the schema creator can now use it to show you a graph of your schema. BUG FIXES: - Fix handling of binary attribute for MySQL columns. Generated SQL for creating/altering these columns may have been invalid previously. - The rules were not catching an attempt to create a CHAR/VARCHAR column with no length (MySQL). - Fixed bug that caused limit to not work when there was a where clause or order_by clause. Reported by Ilya Martynov. - Documented row_column option for MethodMaker. - order_by was ignored when given to the Alzabo::Runtime::Schema->join method. Reported by Martin Ertl. - When viewing an existing column in the schema creator, the three checkboxes at the bottom were always unchecked. - The test suite has been revamped to use Test::More. In the process some new tests were added and some (gulp) false positives were caught. - The default column value wasn't being escaped in the schema creator. DEPRECATIONS - The Alzabo::MethodMaker option 'lookup_tables' has been deprecated. Use the new 'lookup_columns' option instead. INCOMPATIBILITIES: - Alzabo::ObjectCache::Store modules now expect an object id instead of an object for their delete_from_cache method. - If you specify give the 'all' parameter to MethodMaker, 'lookup_tables' is no longer included. 0.56 Had to become 0.57 cause I was too hasty in uploading to CPAN. Doh!
Re: Linux Journal: Alzabo article
On Wed, 26 Sep 2001, Wilson, Doug wrote: > There's an article on Alzabo in this months > Linux Journal. Its also online, just go to > http://www.linuxjournal.com and click on the > picture of the magazine, then look in the toolbox > section of the page. For the posterity of the archives, its at: http://www2.linuxjournal.com/lj-issues/issue90/4887.html -dave /*== www.urth.org We await the New Sun ==*/
ANNOUNCE: Alzabo 0.55
Alzabo is a program and a module suite, with two core functions. Its first use is as a data modelling tool. Through either a schema creation interface or a perl program, you can create a set of schema, table, column, etc. objects to represent your data model. Alzabo is also capable of reverse engineering your data model from an existing system. Its second function is as an RDBMS to object mapping system. Once you have created a schema, you can use the Alzabo::Runtime::Table and Alzabo::Runtime::Row classes to access its data. These classes offer a high level interface to common operations such as SQL SELECT, INSERT, DELETE, and UPDATE commands. Please see http://alzabo.sourceforge.net/ for more info. You can also install Alzabo via CPAN. This release breaks old stuff. Please be careful and email the alzabo list ([EMAIL PROTECTED]) for help first if you're nervous. 0.55 UPGRADE INSTRUCTIONS: Because of changes to the internal data structures for some objects, the saved schema files from older versions of Alzabo will no longer work with this new version. In the eg/ directory of this distribution, there is a script called convert.pl that can be used to convert your schemas. It is _crucial_ that this script be run while you still have your _current_ version of Alzabo installed. To repeat, DO NOT INSTALL THE NEWEST VERSION OF Alzabo BEFORE RUNNING THIS SCRIPT! Now that we've got that straightened out... What this script does is read an existing schema and generate code that you can run after installing the new version of Alzabo. This code will recreate your schema from scratch. It should be noted that this script _will_ reverse the cardinalities of the relationships in your schema. See the entries in BUG FIXES about this. If you don't like this and want it the old broken way, you can run the reverse_cardinality.pl script in the eg/ directory on your schemas. However, you can only do this _after_ installing this new version of Alzabo. So the steps you should take are: 1. Backup all of your schema files (by default, these are stored under /usr/local/alzabo). 2. Run convert.pl against each schema you have created by doing: perl convert.pl This will create a file named _schema.pl 3. After doing this for _all_ of your schemas, install this version Alzabo. 4. Simply run each file created by the convert.pl script. This will overwrite the old schema files. If you are creating your schemas via a script, then you can use the code generated by convert.pl to replace the code that does this. Do note that the cardinalities will be reversed in the generated code. Those who are doing this will notice that the generated code seems to contain everything twice. This has to do with how Alzabo keeps track of changes from one generation of a schema to the next. Simply use the code up to right before the generated code contains the comment "Previous generation of schema". ENHANCEMENTS: - Greatly improved the flexibility of the join and *_outer_join methods for the schema class. It is now possible to construct arbitrary joins between any set of tables in any manner. - Eliminate use of transactions where not needed and shorten their length in other places. Also make sure failed commit triggers a rollback. - Get rid of silly min/max language in favor of cardinality and dependencies. BUG FIXES: - Fixed a problem with syncing after the Unix time rollover to 10 digits. - Alzabo::ForeignKey->is_many_to_one always returned false. - Alzabo::MethodMaker was interpreting foreign key cardinality incorrectly (backwards). This meant it was treating one-to-many relationships as many-to-one. Reported by Martin Ertl. NOTE: This fix will break code that depended on this behavior. See the UPGRADE INSTRUCTIONS above. - This was also broken in Alzabo::Create::Schema->add_relation. I took this opportunity to rewrite the code get rid of the use of min_max_* and replace it with cardinality and dependency, which is easier to understand. NOTE: This fix will break old code that created schemas programmatically. See the UPGRADE INSTRUCTIONS above. DEPRECATIONS: - The Alzabo::Runtime::RowCursor->next_row, Alzabo::Runtime::JoinCursor->next_rows, and Alzabo::Runtime::OuterJoinCursor->next_rows methods have all been deprecated. Instead, simply use the ->next method for all of them. INCOMPATIBILITIES: - The Alzabo::Column->null and Alzabo::Create::Column->set_null methods (deprecated in 0.20) are gone. Use ->nullable and ->set_nullable instead.
Comparison of persistence tools
I just thought I'd let this list know that there's a comparison of persistence tools for Perl at http://poop.sourceforge.net. POOP stands for Perl Object-Oriented Persistence. There's also a mailing list for discussion of such things ([EMAIL PROTECTED]). The document as it stands compares a number of RDBMS-OO mappers as well as some OO-RDBMS mappers, including Class::DBI, Alzabo, and DBIx::RecordSet in the former category and Tangram and SPOPS in the latter. Happy POOPing. -dave /*== www.urth.org We await the New Sun ==*/
Re: parameter unknown: problem with DBD::Pg quote method
On Wed, 29 Aug 2001, Alex Krohn wrote: > If I use mysql, or Oracle, as a driver, it works as expected. I searched > through the list, and the only answer seemed to be to use placeholders, > which isn't really an option in my situation. Why are placeholders not an option? They're generally a good idea, for many reasons (quoting being just one). -dave /*== www.urth.org We await the New Sun ==*/
ANNOUNCE: Alzabo 0.51
Alzabo is a program and a module suite, with two core functions. Its first use is as a data modelling tool. Through either a schema creation interface or a perl program, you can create a set of schema, table, column, etc. objects to represent your data model. Alzabo is also capable of reverse engineering your data model from an existing system. Its second function is as an RDBMS to object mapping system. Once you have created a schema, you can use the Alzabo::Runtime::Table and Alzabo::Runtime::Row classes to access its data. These classes offer a high level interface to common operations such as SQL SELECT, INSERT, DELETE, and UPDATE commands. Please see http://alzabo.sourceforge.net/ for more info. You can also install Alzabo via CPAN. 0.51 BUG FIXES: - Accidentally broke foreign key display for schema creation interface in 0.50. ENHANCEMENTS: - Add ->handle method to Alzabo::Driver class, which lets you set and get the current database handle. Suggested by Ilya Martynov.
ANNOUNCE: Alzabo 0.50
Alzabo is a program and a module suite, with two core functions. Its first use is as a data modelling tool. Through either a schema creation interface or a perl program, you can create a set of schema, table, column, etc. objects to represent your data model. Alzabo is also capable of reverse engineering your data model from an existing system. Its second function is as an RDBMS to object mapping system. Once you have created a schema, you can use the Alzabo::Runtime::Table and Alzabo::Runtime::Row classes to access its data. These classes offer a high level interface to common operations such as SQL SELECT, INSERT, DELETE, and UPDATE commands. Please see http://alzabo.sourceforge.net/ for more info. You can also install Alzabo via CPAN. 0.50 ENHANCEMENTS: - There is now support for left and right outer joins. The interface to this may change a bit in future releases. - Added the following methods to foreign key objects: from_is_dependent, to_is_dependent, is_one_to_one, is_one_to_many, is_many_to_one. - Improved and fixed the Alzabo::MethodMaker documentation. DEPRECATIONS: - In some future release are references to the concept 'min_max_from' and 'min_max_to' will go away. Instead, relationships will be described by their cardinality and dependencies. This was changed in the schema creation interface a while ago but the APIs have not yet completely switched over (there are accessors for the new way, but the set methods still use the old concepts). I'll make sure that there is a time when using these methods issues a warning about their deprecation. BUG FIXES: - Fix pod merging, which broke a while back (this merges superclass documentation into subclasses for things like Alzabo::Runtime::Table). - The code was accidentally serializing a DBI handle, which generates lots of useless warnings. This wasn't affecting Alzabo's operations as it never attempted to use the thawed handle. - Fix handling of ENUM and SET column types for MySQL. These were not being allowed through properly. - Attempting to insert a value into a column that was related to a non-primary key column were not allowed if the value being inserted did not match the related column in the other table, even when the columns were not dependent on each other. Now this is only disallowed when the foreign key is a primary key in its own table.
Re: background sql queries
On Thu, 9 Aug 2001, Giotto De Filippi wrote: > Can I do SQL background queries with DBI? > > like instead of doing ->prepare, ->execute and ->fetchrow_hashref something > like ->is_ready, to do before fetchrow, so for example I could do other > things with my perl program while it's waiting for the sql databsae to > return the result. This won't help if you're truly averse to forking but... Check out Concurrent::Object, which is a very cool module that will help you transparently background and foreground operations using forking (but you don't have to worry about handling the forking yourself). -dave /*== www.urth.org We await the New Sun ==*/
Re: How to use DbFramework.
On Wed, 8 Aug 2001, Matt Kent wrote: > I have a MySql database (ver3.23.39a), Perl 5.6.0, and Apache 1.3.12. > I am looking for a tutorial on how to use the DbFramework module, if there is > any. If not some source code of something using the module would also be good. > I'm using MySql as the database backend to a website. The DbFramework protocols > are going to be used in the online update functions. I myself have looked at DbFramework in the past but didn't find the documentation sufficient to figure out how to use it. There are some projects out there with similar goals, Michael Schwern's Class::DBI and my Alzabo, both of which have more documentation. -dave /*== www.urth.org We await the New Sun ==*/
ANNOUNCE: Alzabo 0.47
Alzabo is a program and a module suite, with two core functions. Its first use is as a data modelling tool. Through either a schema creation interface or a perl program, you can create a set of schema, table, column, etc. objects to represent your data model. Alzabo is also capable of reverse engineering your data model from an existing system. Its second function is as an RDBMS to object mapping system. Once you have created a schema, you can use the Alzabo::Runtime::Table and Alzabo::Runtime::Row classes to access its data. These classes offer a high level interface to common operations such as SQL SELECT, INSERT, DELETE, and UPDATE commands. Please see http://alzabo.sourceforge.net/ for more info. You can also install Alzabo via CPAN. Changes 0.47 ENHANCEMENTS: - Make several of the config values settable via the Alzabo::Config module. Suggested by Jared Rhine. - Transactions should now work under MySQL. Whether it does anything or not depends on the table type you are using. This needs testing though. BUG FIXES: - Make sure that index names are not too long. - Added a missing file to the MANIFEST. 0.46 was missing a needed file from the tarball.
Re: using DBI with Mason for first time
On Tue, 17 Jul 2001, Chabowski wrote:
> I'm testing mason for the first time on our servers, and although mason
> itself is working, I can't seem to get it to recognize DBI. I have
> included "use Apache::DBI;" in my handler.pl file. I have to say I'm a
> novice with DBI, so I'm probably doing something stupid. In my mason
> component file, I make a connect call in the following way:$dbh =
> DBI->connect ($dsn, $user_name, $password) || die qq{DBI error from
> connect: "$DBI::errstr"};
>
>
> I have declared $dsn as: my ($dsn) = "DBI:mysql:test_db"; and declared
> $user_name and $password in a similar fashion. I always get the following
> error message:
> Can't locate object method "connect" via package "DBI" at
> /home/www/mason_data/linguafranca/obj/mason/db_comp.mhtml line 24,
> chunk 1.
>
> Any clues as to what to try next would be greatly appreciated. Thanks for
> taking the time to look this over.
use DBI
Mason is no different than regular Perl. You still have to load the
modules you're using. Apache::DBI does not load DBI (though maybe it
should, come to think of it).
-dave
/*==
www.urth.org
We await the New Sun
==*/
ANNOUNCE: Alzabo 0.46
Alzabo is a program and a module suite, with two core functions. Its first
use is as a data modelling tool. Through either a schema creation
interface or a perl program, you can create a set of schema, table,
column, etc. objects to represent your data model. Alzabo is also capable
of reverse engineering your data model from an existing system.
Its second function is as an RDBMS to object mapping system. Once you have
created a schema, you can use the Alzabo::Runtime::Table and
Alzabo::Runtime::Row classes to access its data. These classes offer a
high level interface to common operations such as SQL SELECT, INSERT,
DELETE, and UPDATE commands.
Please see http://alzabo.sourceforge.net/ for more info. You can also
install Alzabo via CPAN.
This releaes adds the ability to use SQL functions anywhere that you'd
expect, via a very simple interface. For example, this can now be made to
work:
$row->update( mod_time => NOW() );
Changes
0.46
ENHANCEMENTS:
- Column types are now canonized to be all upper case. When multiple
keywords specify the same type ('INT' and 'INTEGER', for example), one
will be chosen. This improves the quality of the reverse engineering
and the usability of the schema creation interface.
- You can now use SQL functions pretty much anywhere you would want
(in inserts, updates, where clauses, etc). See the "Using SQL
Functions" section in the Alzabo.pm docs for more details.
- As a corollary to the above, the Alzabo::Runtime::Table->function
method has been created to replace the old
Alzabo::Runtime::Table->func method. This new method takes advantage
of the new system for using SQL functions and is simpler and more
flexible. It allows you to perform all sorts of aggregate selects.
- Added the Alzabo::Runtime::Row->select_hash method. Requested by
Dana Powers.
DEPRECATIONS:
- The Alzabo::Runtime::Table->func method has been deprecated.
BUG FIXES:
- When adding an AUTO_INCREMENT column to an existing MySQL table, the
SQL generated would cause an error. This has been fixed. However, if
the table already has more than row then chances are this still won't
work (because MySQL does not try to generate needed unique values for
the column when it is added).
Re: Error with SOAP::Lite
On Fri, 29 Jun 2001, Nate Mueller wrote: > (in cleanup) dbih_getcom handle 'DBI::st=HASH(0x880e950)' is not a DBI > handle (has no magic) This happens when a DBI handle is serialized (or if you try to use a previously valid DBI handle after a fork). SOAP is somehow serializing your handle. There is a way to make it not do that but I forgot what it is. -dave /*== www.urth.org We await the New Sun ==*/
Re: DBIx::AnyDBD
On Thu, 21 Jun 2001 [EMAIL PROTECTED] wrote: > Since my last 2 posts prompted absolutely no replies whatsoever my question > is simply this: > > Has anyone implemented DBIx::AnyDBD? > > I realize that this isn't specifically a DBI question, but the perldoc > documentation for DBIx points to this forum. You might try checking on CPAN. (Hint, the answer is yes). search.cpan.org -dave /*== www.urth.org We await the New Sun ==*/
ANNOUNCE: Alzabo 0.45
Alzabo is a program and a module suite, with two core functions. Its first use is as a data modelling tool. Through either a schema creation interface or a perl program, you can create a set of schema, table, column, etc. objects to represent your data model. Alzabo is also capable of reverse engineering your data model from an existing system. Its second function is as an RDBMS to object mapping system. Once you have created a schema, you can use the Alzabo::Runtime::Table and Alzabo::Runtime::Row classes to access its data. These classes offer a high level interface to common operations such as SQL SELECT, INSERT, DELETE, and UPDATE commands. This release incorporates a number of new features and bugfixes. Changes: 0.45 Incompatibilities: - The 'dbm_file' parameter given when loading a syncing module that used DBM files (such as Alzabo::ObjectCache::Sync::SDBM_File) has been changed to 'sync_dbm_file', because this release includes a new cache storage module that uses DBM files as well. - The schema creator now requires HTTP::BrowserDetect. - Fix what was arguably a bug in the caching/syncing code. Previously, one process could update a row and another process could then update that same row. Now the second process will throw an exception. Bug fixes: - Accidentally left debugging turned on in Alzabo::Exceptions. - The schema creator did not allow you to remove a length or precision setting for a column once it had been made. - Require a length for CHAR and VARCHAR columns with MySQL. - Add error on setting precision for any column that doesn't allow them with MySQL. - The interaction of caching rows and Alzabo::MethodMaker was not right. Basically, it was determined at compile time whether or not to use the cached row class but this needs to be determined at run time. This has been fixed. - Using the Alzabo::Runtime::Row->rows_by_foreign_key method would fail when the column in one table did not have the same name as a column in the other table. Reported by Michael Graham (along with a correct diagnosis, thanks!). - Don't specify a database name when creating or dropping a database. Reported and patched by Dana Powers. Enhancements: - Rules violations error messages (bad table name, for example) in the schema creator are now handled in a much friendlier manner. Instead of the big error dump exception page it returns you to the page you submitted from with an error message. - Add Alzabo::Create::Column->alter method which allows you to change the column type, length, and precision all at once. This is necessary because some of the column type validation code will insist that a column have a length setting. If you try to change them in two separate operations it will throw an exception. - Add Alzabo::ObjectCache::Store::Null - This allows you to use any multi-process syncing module without using up the memory that Alzabo::ObjectCache::Store::Memory uses. - Add Alzabo::ObjectCache::Store::BerkeleyDB - I'm not sure if storing in a db file is really a performance win (vs. null storage) because of the work needed to freeze & thaw the row objects. Benchmarks are needed. - Add support for fulltext indexes (MySQL). - Don't show fulltext or column prefix options when creating indexes for databases that don't support these features. - Use cardinality & dependency language for relations. - Add some style to the schema creator (via stylesheets). It looks a little better now.
ANNOUNCE: Alzabo 0.44
Alzabo is a program and a module suite, with two core functions. Its first use is as a data modelling tool. Through either a schema creation interface or a perl program, you can create a set of schema, table, column, etc. objects to represent your data model. Alzabo is also capable of reverse engineering your data model from an existing system. Its second function is as an RDBMS to object mapping system. Once you have created a schema, you can use the Alzabo::Runtime::Table and Alzabo::Runtime::Row classes to access its data. These classes offer a high level interface to common operations such as SQL SELECT, INSERT, DELETE, and UPDATE commands. This is mostly a bugfix release with one nice new feature in the schema creator. Changes: 0.44 Bug fixes: - Bug fix in Alzabo::Runtime::Table->set_prefetch. Reported by Bob Gustafson. - Don't try to make directories when running Makefile.PL. Save it for later after user does 'make install'. - Fix handling of geometric types in Postgres (they were all being rejected as invalid). - Drop columns from a table before adding new ones. Sometimes this makes a difference. For example, if you are using MySQL and drop an existing AUTO_INCREMENT column and add a new one that is also AUTO_INCREMENT. - Only allow one sequenced column per table when using MySQL. - Doc fixes. Thanks to Ron Savage for pointing me towards some of these. - Fix a bug with the schema creator. If you attempted to make a change to a column with an extended type and you did not change the type, an error occurred. Enhancements: - Schema creator now shows you a list of possible column types instead of having you type it in. However, for complex types like MySQL's ENUM or Postgres' POLYGON there is a text box to type it in.
Re: How to retireve table structure using DBI?
On Thu, 3 May 2001, David H. Silber wrote: > I've also stumbled upon DBIx::DBSchema, which is supposed to help me > extract schema information from a database. > > Does anyone know how Alzabo & DBIx::DBSchema compare? Or do they > compare at all? > > What I need is to get the complete schema and grant information from a > database. This should be done in as generic a manner as possible, > because we intend to work with multiple database engines in the future. Alzao is not intended (at least not yet) to be a tool for sysadmins. Rather, it is a data modeller. As such, I haven't even considered trying to store grant information or info on users and such. This may happen in the future but I don't know when. I think DBIx::DBSchema has most of the features Alzabo has. One cool feature Alzabo has that DBIx::DBSchema does not is that Alzabo is able to generate SQL 'diffs'. If you give it two schema objects it can generate all the SQL statements necessary to turn one into the other. The two schemas must be for the same RDBMS, however. -dave /*== www.urth.org We await the New Sun ==*/
Re: How to retireve table structure using DBI?
On Thu, 3 May 2001, Bob Gustafson wrote: > There is an interesting project on sourceforge called Alzabo, which > provides an html database interface using DBI, Perl with mason and > mod_perl/apache for both design and browsing of database tables. It uses > mysql and/or oracle and/or postgresql. It doesn't support Oracle yet, actually. Soon, I hope (someone donated a fair amount of the code needed but I still need to finish it up). FWIW, Alzabo uses DB specific stuff internally for each RDBMS when doing reverse engineering. I've been meaning to look into the abstracted DBI methods to see if I could use those as well. It won't ever completely replace it because for Alzabo I need to find things like indexes and such. -dave /*== www.urth.org We await the New Sun ==*/
ANNOUNCE: Alzabo 0.41
The recently announce 0.41 release ws missing a file from the tarball. http://alazabo.sourceforge.net/
ANNOUNCE: Alzabo 0.40
Alzabo is a program and a module suite, with two core functions. Its first use is as a data modelling tool. Through either a schema creation interface or a perl program, you can create a set of schema, table, column, etc. objects to represent your data model. Alzabo is also capable of reverse engineering your data model from an existing system. Its second function is as an RDBMS to object mapping system. Once you have created a schema, you can use the Alzabo::Runtime::Table and Alzabo::Runtime::Row classes to access its data. These classes offer a high level interface to common operations such as SQL SELECT, INSERT, DELETE, and UPDATE commands. This release is a fairly big one, incorporating a bunch of new code (including much faster caching modules) and bug fixes. Changes: 0.40 Incompatibilities: The classes in the ObjectCache hierarchy have been reorganized. The renaming is as follows: Alzabo::ObjectCache::MemoryStore => Alzabo::ObjectCache::Store::Memory Alzabo::ObjectCache::DBMSync => Alzabo::ObjectCache::Sync::DB_File Alzabo::ObjectCache::IPCSync => Alzabo::ObjectCache::Sync::IPC.pm Alzabo::ObjectCache::NullSync=> Alzabo::ObjectCache::Sync::Null.pm Enhancements: - Document order by clauses for joins. - Document limit clauses for joins and single table selects. - Expand options for where clauses to allow 'OR' conditionals as well as subgroupings of conditional clauses. - If you set prefetch columns for a table, these are now fetched along with other data for the table in a cursor, reducing the number of database SELECTs being done. - Added Alzabo::Create::Schema->clone method. This allows you to clone a schema object (except for the name, which must be changed as part of the cloning process). - Using the profiler, I have improved some of the hot spots in the code. I am not sure how noticeable these improvements are but I plan to do a lot more of this type of work in the future. - Added the Alzabo::ObjectCache::Sync::BerkeleyDB and Alzabo::ObjectCache::Sync::SDBM_File modules. These modules are much faster than the old DBMSync or IPCSync modules and actually appear to be faster than not syncing at all. The NullSync (now Sync::Null) module is still faster than all of them, however. Bug fixes: - Reversing engineering a MySQL schema with ENUM or SET columns may have caused an error if the values for the enum/set contained spaces. - A bug in the schema creation interface made it impossible to create an index without a prefix. Reported by Sam Horrocks. - When dropping a table in Postgres, the sequences for its columns (if any), need to be dropped as well. Adapted from a patch submitted by Sam Horrocks. - The modules needed by the schema creator and data browser are now used by the components. However, it is still better to load them at server startup in order to maximize shared memory. - Calling the object cache's clear method did not work when using the IPCSync or NullSync modules. - Reverse engineering a Postgres database was choking on char(n) columns, which are converted internally by Postgres into bpchar(n) columns. This is now fixed (by converting them back during reverse engineering). - Reject column prefixes > 255 with MySQL. I hesitate to call this a bug fix since this appears to be undocumented in the MySQL docs. - Using the DBMSync module in an environment which started as one user and then became another (like Apache) may have caused permiission problems with the dbm file. This has been fixed. Misc: - Require DBD::Pg 0.97 (the latest version as of this writing) as it fixes some bugs in earlier versions. Architecture: - Split up Row object into Alzabo::Runtime::Row (base class for standard uncached row) and Alzabo::Runtime::CachedRow (subclass for rows that have to interact with a cache). This simplifies the code, particulary in terms of how it interacts with the caching system. - Made Alzabo::Runtime::Row->get_data a private method. This served no purpose for end users anyway.
ANNOUNCE: Alzabo 0.36
Alzabo is a program and a module, with two core functions. Its first use is as a data modelling tool. Through either a schema creation interface or a perl program, you can create a set of schema, table, column, etc. objects to represent your data model. Alzabo is also capable of reverse engineering your data model from an existing system. Its second function is as an RDBMS to object mapping system. Once you have created a schema, you can use the Alzabo::Runtime::Table and Alzabo::Runtime::Row classes to access its data. These classes offer a high level interface to common operations such as SQL SELECT, INSERT, DELETE, and UPDATE commands. More information is available at http://alzabo.sourceforge.net/ Alzabo can be downloaded from CPAN or from Sourceforge at http://sourceforge.net/projects/alzabo/ This release contains major bugfixes for problems introduced in the 0.35 release. Changes for 0.36 - Addition of Params::Validate broke several methods: -- The Alzabo::Schema->tables method was broken when trying to retrieve a subset of all the tables. -- The Alzabo::Create::Schema->move_table method was broken (thus breaking the ability to add a table at a specified place in the table order). -- Same problem for Alzabo::Create::Table->move_column. - Added to the test suite to catch all this in the future. - Attempting to dynamically generate component paths in the Mason component was a bad idea, particularly since it was unnecessary because I can find the component by doing '../common/foo'. Thanks to Bob Gustafson for suggesting this. - Fix bug in Postgres rules that didn't allow length for CHAR columns. - Fixed problems running multi-process tests with Postgres.
ANNOUNCE: Alzabo 0.35
Alzabo is a program and a module, with two core functions. Its first use is as a data modelling tool. Through either a schema creation interface or a perl program, you can create a set of schema, table, column, etc. objects to represent your data model. Alzabo is also capable of reverse engineering your data model from an existing system. Its second function is as an RDBMS to object mapping system. Once you have created a schema, you can use the Alzabo::Runtime::Table and Alzabo::Runtime::Row classes to access its data. These classes offer a high level interface to common operations such as SQL SELECT, INSERT, DELETE, and UPDATE commands. More information is available at http://alzabo.sourceforge.net/ Alzabo can be downloaded from CPAN or from Sourceforge at https://sourceforge.net/projects/alzabo/ Changes for 0.35 0.35 - Add ability to specify port parameter when connecting to DB for reverse engineering/data browser. - Fix support for host param in data browser. - Added a new Alzabo/FAQ.pod file. Its pretty skimpy but hopefully it will become more useful over time. - If your Mason component root was under your document then the links to return to the top levels of the schema creator and data browser were broken. Note: if your component root is entirely outside your document root then things may not work at all. - Add support for extra MySQL connection params (like mysql_default_file). See the Alzabo::Driver::MySQL docs for more details. - Add support for Postgres connect params 'options' and 'tty'. - Alzabo::Create::Schema->reverse_engineer was not passing the 'port' parameter to the driver when attempting to make a driver. - Attempting to pass in the port parameter to a connection would have generated a bad DSN due to a type in the code. - Started using Params::Validate so I can be even stricter about argument checking. - Fix bug introduced in 0.33. Changing a column's type always removed any length and precision setting for the column. Now it is only removed if the new column type does not allow a length or precision setting. - Fix some warnings in the Makefile.PL code. Also require Pod::Man >= 1.14 to handle =head3 and =head4 directives. - The Postgres code did not allow the ABSTIME, MACADDR, or RELTIME column types. These have been added. Thanks to Bob Gustafson for helping me find this problem. - The Alzabo::Create::Schema->reverse_engineer method was not doing anything with a host parameter. Reported by Aaron Johnson. - Fix bug in Alzabo::ObjectCache docs. Reported by Robin Berjon. - Include a first version of the quick method reference suggested by Robin Berjon. This Alzabo::QuickRef. The HTML version is table-ized and spiffed up a bit from the POD version.
ANNOUNCE: Alzabo 0.34
Alzabo is a program and a module, with two core functions. Its first use is as a data modelling tool. Through either a schema creation interface or a perl program, you can create a set of schema, table, column, etc. objects to represent your data model. Alzabo is also capable of reverse engineering your data model from an existing system. Its second function is as an RDBMS to object mapping system. Once you have created a schema, you can use the Alzabo::Runtime::Table and Alzabo::Runtime::Row classes to access its data. These classes offer a high level interface to common operations such as SQL SELECT, INSERT, DELETE, and UPDATE commands. More information is available at http://alzabo.sourceforge.net/ Alzabo can be downloaded from CPAN or from Sourceforge at https://sourceforge.net/projects/alzabo/ Changes for 0.34 0.34 - If you were trying to run the tests on a system without MySQL installed, or without the DB_File or IPC::Shareable modules, you saw lots of test failures, even if you said you did not plan to use the parts of Alzabo that required these. This has been fixed. I can now run the tests successfully using a Perl with only DBD::Pg and DBI installed and it will skip any tests that it can't run. - Fixed another caching bug related to objects that were deleted and then another row was inserted with the same primary key. Note to self: premature optimization is the root of all evil.
ANNOUNCE: Alzabo 0.33
Alzabo is a program and a module, with two core functions. Its first use is as a data modelling tool. Through either a schema creation interface or a perl program, you can create a set of schema, table, column, etc. objects to represent your data model. Alzabo is also capable of reverse engineering your data model from an existing system. Its second function is as an RDBMS to object mapping system. Once you have created a schema, you can use the Alzabo::Runtime::Table and Alzabo::Runtime::Row classes to access its data. These classes offer a high level interface to common operations such as SQL SELECT, INSERT, DELETE, and UPDATE commands. This release is mostly bug fixes with a few new features. Upgrading is recommended because some of the bugs can be annoying though none are catastrophic Changes: 0.33 - The linking table methods generated by Alzabo::MethodMaker were broken. Fixed this. - Changed how order by clauses can be passed to select operations. Also changed the docs, which were way out of sync with the changes in this area. - Attempting to update more than one value at once was broken. Fixed this. - Added Alzabo::Runtime::Table->func method to allow arbitrary column aggregate functions like MAX, MIN, AVG, etc. - Fixed schema creator bug. It was not possible to change a column's NULLability after it was created. - When changing a column's type, Alzabo now removes any column attributes that are not valid for that column. In addition, if the existing length and precision parameters are not valid, they will be set to undef. - Fixed the code to get rid of weird error messages that came from DBI with Perl 5.6.0+ when the Alzabo::Create::Schema->create or Alzabo::Create::Schema->reverse_engineer methods were called. For the curious, this has to do with the DBI object passing through Storable::dclone.
Re: Strange error message with DBI (any driver) and Perl 5.6.0+
On Sun, 11 Feb 2001, Dave Rolsky wrote: > I get a slew of these messages when my code finishes running, but only > when using Perl 5.6.0 (I also tried 5.6.1 trial1). So I finally tracked this down to a DBI handle passing through Storable's dclone function. I made this not happen and the messages went away. -dave /*== www.urth.org We await the New Sun ==*/
Strange error message with DBI (any driver) and Perl 5.6.0+
I get a slew of these messages when my code finishes running, but only
when using Perl 5.6.0 (I also tried 5.6.1 trial1).
Here's a sample:
SV = RV(0x844c874) at 0x844eb94
REFCNT = 1
FLAGS = (ROK)
RV = 0x8458ae4
(in cleanup) dbih_getcom handle 'DBI::db=HASH(0x8458ae4)' is not a
DBI handle (has no magic) during global destruction.
SV = RV(0x845d8b8) at 0xb638
REFCNT = 1
FLAGS = (ROK,READONLY)
RV = 0x8458ae4
SV = RV(0x844c86c) at 0x844ec48
REFCNT = 1
FLAGS = (ROK)
RV = 0x844ec54
(in cleanup) dbih_getcom handle 'DBI::dr=HASH(0x844ec54)' is not a
DBI handle (has no magic) during global destruction.
SV = RV(0x844c850) at 0xb338
REFCNT = 1
FLAGS = (ROK,READONLY)
RV = 0x844ec54
I get one such pair ('DBI::db' & 'DBI::dr') for each database handle
created by Alzabo.
Turning on tracing just before the end of the app yielded only this (at
trace level 9):
-> DESTROY for DBD::mysql::db (DBI::db=HASH(0x8457cd8)~INNER)
<- DESTROY= undef during global destruction.
This is not affecting the code but since Alzabo is being used by others
I'd like to get this cleaned up. I've tried various things such as
disconnecting the database handle earlier or later, explicitly undef'ing
it, etc. None of this works.
I emailed about this about 3 weeks ago but didn't get any responses, which
may be because my subject line was not very useful.
-dave
/*==
www.urth.org
We await the New Sun
==*/
ANNOUNCE: Alzabo 0.32
Alzabo is a two-fold program. Its first function is as a data modelling tool. Through either a schema creation interface or a custom perl program, you can create a set of schema, table, column, etc. objects that represent your data model. Alzabo is also capable of reverse engineering an existing data model. Its second function is as a RDBMS to object mapping system. Once you have created a schema, you can use the Alzabo::Runtime::Table and Alzabo::Runtime::Row classes to access its data. These classes offer a high level interface to common operations such as SQL SELECT, INSERT, DELETE, and UPDATE commands. Just one change since 0.31: 0.32 - Forgot to include data browser files in MANIFEST. Caused weirdness if you said you wanted it when asked during install. Reported by Remi Cohen-Scali.
ANNOUNCE: Alzabo 0.31
It seems like only yesterday I released 0.30. Oh, I did. Ok, I found some bugs today and figured it'd be best to get a bug fix release out. Here's the changes: 0.31 - Fix bugs in Alzabo::MethodMaker. The insert, update, lookup_table, and self_relation (parent portion only) were broken. - A bug in the SQL making code was causing some queries to appear as if they failed when they didn't.
ANNOUNCE: Alzabo 0.30
Alzabo is a two-fold program. Its first function is as a data modelling tool. Through either a schema creation interface or a custom perl program, you can create a set of schema, table, column, etc. objects that represent your data model. Alzabo is also capable of reverse engineering an existing data model. Its second function is as a RDBMS to object mapping system. Once you have created a schema, you can use the Alzabo::Runtime::Table and Alzabo::Runtime::Row classes to access its data. These classes offer a high level interface to common operations such as SQL SELECT, INSERT, DELETE, and UPDATE commands. Here's the change log: Please note that if you have existing schema objects you want to convert you need to run the eg/convert.pl script _before_ installing 0.30. 0.30 - The convert.pl script in eg/ has been updated to handle the new release. IMPORTANT: I forgot to include a mention of this in the last release but you need to run the script _before_ installing a new version of Alzabo. - Many improvements and updates to Alzabo::MethodMaker. Highlights include fixing a bug that prevented the insert and update methods from being created, a new callback system that allows you to specify all the method names to be generated, and a new 'self_relations' option for tables that have parent/child relationships with themself. - Fix handling of NULL columns for inserts and updates. Now, Alzabo only throws an exception if the column is not nullable and has no default. If it has a default and is specified as NULL then it will not be included in the INSERT clause (in which case the RDBMS should insert the default value itself). - Fix bugs in Postgres reverse engineering. Defaults were not handled properly, nor were numeric column type length and precision. - The schema creator and data browser now allow you to enter the host for database connections where needed. - Foreign keys can now span multiple columns. This means you can have a relation from foo.foo_id and foo.index_id to bar.foo_id and bar.index_id. This required some changes to the interface for the foreign key objects. Notably, the Alzabo::ForeignKey->column_from and Alzabo::ForeignKey->column_to methods are now Alzabo::ForeignKey->columns_from and Alzabo::ForeignKey->columns_to. In addition, the parameters given to the Alazbo::Create::Schema->add_relation have changed. - Major changes to caching architecture. The caching code has been split up. There is now a 'storing' class, which holds onto the objects (the cache). Then there is a 'sync' class. This class handles expiration and deletion tracking. These two classes can be mixed and matched. Right now there is only one storage class (which stores the objects in memory). There are 3 syncing classes. One, NullSync, doesn't actually sync objects. It does track deletions, but not expirations. The others, IPCSync and DBMSync, use IPC or DBM files to track expiration and deletion of objects. - Doing this work highlighted some bugs in the caching/syncing code. One oversight was that if you deleted an object and then inserted another row with the exact same primary key, the cache continued to think the object was deleted. Other bugs also surfaced. These have been fixed and the test suite has been updated so caching should be stable (if not, I'll have to cry). - When viewing an existing column in the schema creator, defaults, lengths, and precision of 0 were not being shown. - Alzabo::Runtime::Table->row_count can now take a where clause. - Fix bugs in Alzabo::Create::Table. This was causing problems with indexes when the table name was changed. - Fixed a bug in Alzabo::Util that caused the test cases to fail if Alzabo hadn't been previously installed. Reported by Robert Goff. - The SQLMaker class is now smarter about not letting you make bad SQL. For example, if you try to make a WHERE clause with tables not mentioned in the FROM clause, it will throw an exception. This will hopefully help catch logic errors in your code a bit sooner. - Removed use of prepare_cached in Alzabo::Driver. This has the potential to cause some strange errors under Alzabo. Because of the way Alzabo works, it is possible to have a Cursor object holding onto a statement handle that needs to be used elsewhere (by a row object, for example). It is safer to let a new statement handle be created in this case. INCOMPATIBILITIES - See the note above about the changes required to support multi-column foreign keys. - Because of the aforementioned changes to the caching architecture, caching just does not work the way it used. 1. By default, there is no caching at all. 2. To get the old behavior, which defaulted to an in-process memory cache with no inter-process syncing (meaning deletes are tracked but there is no such thing as expiration), you can do this in your code: use Alzabo::ObjectCache( store => 'Alzabo::ObjectCache::MemoryStore', sync => 'Alzabo::ObjectCache:
