Design Flaws in DBIx::Connect

DBIx::Connect came into being after repeated patch submissions to the author of DBIx::Password were rejected. So I designed the module based on practical immediate needs and it was useful enough for other people that wanted to make mods that I put it on sourceforge.

Now I am on a new database-project and just realized something: there is more to configuring a database application than setting up a database connection.

In particular, right now, I need to have information about which table is my master table, which table is my leads table, etc. And of course, the initial call to DBIx::Connect should return more than a $dbh, it should return the configuration object also.

Now, if all the methods of the module returned a scalar as its first argument, it would be simply a matter of returning the configuration object as a second scalar. But I was short-sighted and returned arrays and hashes for the methods which returned aggregates:

# DBIx::AnyDBD usage:
 my @connect_data = DBIx::Connect->data_array('dev_db');
 my $dbh          = DBIx::AnyDBD->connect(@connect_data, "MyClass");

 # Alzabo usage
 my %connect_data = DBIx::Connect->data_hash('dev_db');
[download]

And why? It certainly is less efficient to return copies than references.

But now I am stuck with my design decision unless I make a major API change and have every call return a scalar as its first argument. The other option is to have one call to get the connection information or database handle and make a second call for a configuration object, but this inefficient and doubles the lines of code needed for using the module.

I think I will just make the API change as no one uses this module with Alzabo or DBIx::AnyDBD other than me.

Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality

Comment on Design Flaws in DBIx::Connect Select or Download Code

Replies are listed 'Best First'.
Re: Design Flaws in DBIx::Connect by belg4mit (Prior) on Jul 22, 2003 at 16:31 UTC
Couldn't you extend the current API? Send a flag to the sub that indicates you wish the behavior to be different, thusly not breaking prexisting uses. `-- I'm not belgian but I play one on TV.`	[reply]
Re: Re: Design Flaws in DBIx::Connect by Dog and Pony (Priest) on Jul 22, 2003 at 17:11 UTC
Or if that is a "bad" idea due to variable number of arguments or something like that, why not simply introduce a new call, parallell to the old one, something like `connect_with_config` or some such. Then old users would be safe, and new users could choose which they need. You have moved into a dark place. It is pitch black. You are likely to be eaten by a grue.	[reply] [d/l]
Re: Design Flaws in DBIx::Connect by princepawn (Parson) on Jul 22, 2003 at 17:48 UTC
Aha! I think what I will do is add "sister" methods: Parallel to `data_array` will be `data_aref` which returns an array reference AND the config object. Parallel to `data_hash` will be `data_href` which returns a hash reference AND the config object. Parallel to `to` will be `toc` which returns a `$dbh` AND the config object. But I really need to think about where table information belongs... should it be with the database connection configuration information? Likely, it may be global to several such config nodes because you may have numerous ways to connect to the same database (ie, different attributes set, different hosts), but you want the table information to be the same across the various connection configurations. It may or may not be wise to include the table information in the same file. This will require some reflection. Carter's compass: I know I'm on the right track when by deleting something, I'm adding functionality	[reply] [d/l] [select]


P is for Practical
	PerlMonks