[Dbix-class] Weird things you'd like to do with DBIx::Class.

[Todd Holbrook]

Matt asked for some use cases of things that we'd like to see possible
with DBIx::Class.  I wrote a very hacked CDBI::Relationship module
that I'd never release to the public because it's possibly a really
bad idea and is likely to break outside of the current CDBI version. 
I started it on 0.95 and migrated it to 0.96 though I'm sure it's not
done the "right" way (using __meta_info?).  Though it may not be a
good general public thing, it is extremely useful in the applications
I work on where new data fields show up regularly and users are
writing their own templates and shouldn't have to know if something is
"new and extra" data or core data.

Here's the quick info I typed up for the pod:
                                                                
DESCRIPTION

Relationship module for Class::DBI that adds extra fields to a table
object based on field/value pairs in another table.  This can be handy
if you have some base information that belongs to most records and
extra information that belong to a small subset but you want to treat
them the same when using the object.  It is also handy if you are
working with data where new fields show up regularly that belong to a
subset of the data and you don't want to have to make regular schema
changes.  It's not as useful when it's data you want to search on
often, use as a foreign key, etc.  I call these bits of information
"details".

These fields work pretty much the same as a native table field if you
use the generated accessors on them.  It does not override set() or
get() to allow for accessing them that way.  I haven't tried setting
triggers or validation or anything like that either, though it may
work.

Here's an example based on the included test file.

You have a basic Movie table with the title and release year of the
movie.  You don't know what extra information you might want to store
later (genre, tagline, price, etc.).  So you create an attached
details table where you can add these extra fields without changing
the database code, though it does require adding it to the field list
in the CDBI table class, obviously.

So you create the basic Movie table:

         movie
         -------------------------
         id    INTEGER PRIMARY KEY
         title VARCHAR(1024)
         year  INTEGER

and a details table:

         movie_details
         -------------------------
         id       INTEGER PRIMARY KEY
         movie    INTEGER
         field    VARCHAR(1024)
         value    VARCHAR(1024)

and use CDBI::R::HasDetails to link them:

         package My::Movie;

         use base 'My::DBI';

         use Class::DBI::Relationship::HasDetails;
         __PACKAGE__->table('Movies');
         __PACKAGE__->columns(All => qw/id title year/);

         __PACKAGE__->has_details('details', 'My::MovieDetails' => 'movie');
         __PACKAGE__->details_columns(qw(tagline genre price));

More example code can be found in the attached test file.  The
HasDetails::Relationship code is also attached, though I don't
recommend anyone actually try it.  Hopefully attachments work for the
list, otherwise I'll resend with code in the body.

Todd
--
Todd Holbrook
Systems Consultant
Simon Fraser University
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 01.t
Type: application/x-troff
Size: 4687 bytes
Desc: not available
Url : http://lists.rawmode.org/pipermail/dbix-class/attachments/20050728/dfef0250/01.t
-------------- next part --------------
A non-text attachment was scrubbed...
Name: HasDetails.pm
Type: application/octet-stream
Size: 11541 bytes
Desc: not available
Url : http://lists.rawmode.org/pipermail/dbix-class/attachments/20050728/dfef0250/HasDetails.obj