From: Dave Rolsky <autarch@ur...> - 2002-06-14 21:53:39
On Fri, 14 Jun 2002, James G Smith wrote:
> (1) changing the definition of a column in one table should change
> the equivalent column in any dependent tables. I don't see this
> happening right now, at least in the documentation.
> Another thing that would be related would be to import the
> definition of the column from the independent table to the
> dependent one when the add_relation method is used (if the
> column is not already defined -- perhaps this would mark the
> column then for maintenance as described in the first part).
> This would be useful if a key column had to be made wider (for
> example). Instead of trying to find all the tables that need to
> be modified, modifying the master table should go through and
> modify all the dependent tables, at least if referential
> integrity is being enforced.
Actually, this does exist. If you call the schema object's
->add_relationship method and you don't specify any columns, then Alzabo
will figure out which columns to use, _and_ make sure that they share the
same underlying definition (which is type, length & precision but not
attributes, nullability, comment, sequenced, etc.)
This can be done explicitly in code by re-using one column's
Alzabo::Create::ColumnDefinition object when creating another column.
It's good but not perfect. For example, _some_ attributes _should_ be
shared, the unsigned attribute available in MySQL, while others like
UNIQUE in Postgres, should not.
Eventually, I'll make that all work too.
The schema creator does take advantage of this feature when creating
relationships if you select the "Let Alzabo choose" option when it asks
what columns to use in the relationship.
The whole feature probably could be redone a bit more gracefully,
actually, by simply storing "dependent columns" in each column (or having
it find them by following foreign keys).
This change involves changing data structures, and since Alzabo serializes
schemas to disk using Storable, changes to data structures are somewhat of
a pain. Fortunately, the Alzabo::BackCompat module I recently wrote lets
me transparently upgrade older data structures, but it still requires a
lot of testing, so I try to make data structure changes infrequently.
All of which is to say that this feature will be improved, but it might
take a while ;)
> (2) Allow connection to an already-established database handle.
> Instead of specifying the host/username/password info, do
> something like
> my $schema = Alzabo::Runtime::Schema
> -> load_from_file( name = 'foo' );
> dbh => $dbh
> Are there any dependencies in Alzabo on the
> username/password/hostname/port ? Perhaps if a handle is passed
> the driver should do something like `use $database' to get to the
> right place.
> Number (1) I don't think I can do, but (2) I should be able to and
> submit a patch, if it seems worthwhile (I'll probably do it anyway
> since that's what I need :/).
A patch plus docs and tests would be great ;)
You'll need to change Alzabo::Driver::MySQL & ::PostgreSQL's _make_dbh
Should be pretty simple.
we await the New Sun