Upstream changes:
0.39 Fri Mar 26 20:24:58 PDT 2010
- mysql: TEXT->LONGTEXT
- mysql: when reverse engineering, transform a default of
CURRENT_TIMESTAMP into the more common NOW()
- mysql: fix reverse-engineering of empty string default
to trigger/signal a rebuild for the transition 5.10.1 -> 5.12.1.
The list of packages is computed by finding all packages which end
up having either of PERL5_USE_PACKLIST, BUILDLINK_API_DEPENDS.perl,
or PERL5_PACKLIST defined in their make setup (tested via
"make show-vars VARNAMES=..."), minus the packages updated after
the perl package update.
sno@ was right after all, obache@ kindly asked and he@ led the
way. Thanks!
pkgsrc changes:
- Adjusting dependencies
- Adding license definition
Upstream changes:
0.38 Thu Jan 14 15:26:13 PST 2010
- Bump version number for ->quoted_default availability & default
reverse-engineering changes
0.37 unreleased
- Patch from Slavin Rezic <srezic@cpan.org> to prevent quoting around
numeric defaults in Pg.
- Pg: use default_db_schema when adding SERIAL columns instead of
hardcoding "public".
- Pg: Initial support for handling changes to a column's type or size.
- Case sensitivity fix for Slavin's patch to prevent quoting around
numeric defaults in Pg.
- Column default values: refactor handling, improve Pg reverse
engineering and implement schema changes.
to trigger/signal a rebuild for the transition 5.8.8 -> 5.10.0.
The list of packages is computed by finding all packages which end
up having either of PERL5_USE_PACKLIST, BUILDLINK_API_DEPENDS.perl,
or PERL5_PACKLIST defined in their make setup (tested via
"make show-vars VARNAMES=...").
0.36 Thu Dec 13 17:49:35 PST 2007
- Patch from ISHIGAKI@cpan.org to suppress unnecessary warnings about
undefined local_options, thanks!
- fix bug preventing adding new columns as primary keys under Pg
0.35 Mon Oct 29 18:58:36 PDT 2007
- Fix minor breakage (pretty_print) resulting from Jesse's changes.
- Update mysql driver to handle BIGSERIAL columns
- Update Column.pm, move all mysql and Pg-specific code to DBD driver
callbacks
- Update Table.pm, add local_options
- Fix mysql NULL reverse-engineering and updating code
0.34 Sun Aug 19 10:08:51 PDT 2007
- More work on update schema from Slaven Rezic <srezic@cpan.org>,
thanks!
+ implement table dropping (closes: CPAN#27936)
+ implement column dropping (closes: CPAN#27896)
- Fix to quiet warnings from internal use of old API from Jesse Vincent
<jesse+cpan@fsck.com>, thanks! (closes: CPAN#27958)
- Make table dropping optional, not the default.
0.33 Thu Jun 28 18:46:15 PDT 2007
- Overhaul of index representation: indices (both normal and unique)
now have names and are DBIx::DBSchema::Index objects
- update_schema now handles indices!
- Bump version numbers in Table.pm, Column.pm and DBD.pm
- Pg reverse-engineering fix for column order in multi-column indices,
to prevent needless drop/add of identical indices
- mysql reverse-engineering patch from Brian Phillips
<bphillips@cpan.org>, closes: CPAN#17582, thanks!
- mysql NAME vs NAME_lc patch from Ralf Hack <ralf@beetlecraft.net>,
closes: CPAN#16715, thanks!
- mysql fix for additional column data from Chris Mungall
<cjm@fruitfly.org>, closes: CPAN#20859, thanks!
- SQLite SERIAL patch from IN SUK JOUNG <i.joung@gmail.com>, and fix
for mis-application of said patch from Slaven Rezic
<srezic@cpan.org>, thanks!
- Update README wrt current CVS info and URL, closes: CPAN#27577
0.32 Wed Apr 18 15:02:25 PDT 2007
- increment the version numbers in Column.pm and Table.pm and the
"use" statements accordingly
- Error reporting for load constructor
- Update documentation wrt supported databases and new update_schema
stuff
- Fixes for dropping nullability on old Pg (<= 7.2)
- Fixes for adding nullability on old Pg (<= 7.3)
- Throw a warning if pg_server_version is unavailable, assume >= 7.3
- fix POD error in DBSchema::DBD::SQLite that confused pod2man and
prevented the documentation from being installed. Patch from Niko
Tyni <ntyni@iki.fi>, thanks!
0.31 Thu Mar 30 05:28:20 PST 2006
- more schema update stuff:
- added Column::sql_alter_column
- added Table::sql_alter_table
- added DBSchema::sql_update_schema and DBSchema::update_schema
0.30 Thu Feb 16 16:43:01 PST 2006
- "Too much uptime"
- Remove buggy debugging from Column.pm
- Remove removed TODO from MANIFEST
0.29 Thu Feb 16 13:54:42 PST 2006
- Column::sql_add_column fix when adding primary keys to Pg 7.2.x
- workaround for PAUSE parsing of DBIx::DBSchema::DBD::Pg version: move
DBD::Pg verison checking after $VERSION declaration, thanks Andreas!
- kludge: allow scalar ref default to force quoting off, to add things
like functions and empty values as defaults
- Move TODO file to DBSchema.pm and DBS/Column.pm BUGS sections
0.28 Wed Nov 30 09:46:47 PST 2005
- Initial SQLite support from Jesse Vincent
- fix typo in DBIx::DBSchema::DBD POD doc
developer is officially maintaining the package.
The rationale for changing this from "tech-pkg" to "pkgsrc-users" is
that it implies that any user can try to maintain the package (by
submitting patches to the mailing list). Since the folks most likely
to care about the package are the folks that want to use it or are
already using it, this would leverage the energy of users who aren't
developers.
This module implements an OO-interface to database schemas. Using
this module, you can create a database schema with an OO Perl
interface. You can read the schema from an existing database.
You can save the schema to disk and restore it from different
process. Most importantly, DBIx::DBSchema can write SQL CREATE
statements for different databases from a single source.
Currently supported databases are MySQL, PostgreSQL, Oracle and
Sybase. DBIx::DBSchema will attempt to use generic SQL syntax for
other databases. Assistance adding support for other databases is
welcomed.
This module helps abstract the process of working with complex
schemas of relational SQL database tables. As with DBI, it lets
you work with data a row at a time, but gives you the extra ability
to, with a single method call, reach across and grab rows of related
data from tables located elsewhere in your database, without having
to construct an SQL join clause yourself. The 'distance' from the
originating table to the related one can be arbitrarily long, so
long as they are related in some way -- i.e., could both return
data through a single (though perhaps quite lengthy) SQL query.
