[Dbix-class] RFC: Thoughts on a serialization format for Classes

[Rob Kinyon]

On 7/29/07, John Napiorkowski <jjn1056 at yahoo.com> wrote:
> I think the main idea is to push stuff into a
> configuration file when it's not code that doing
> logical work.  This way I can push down some simple
> maintenance work to admins.  Also I've been playing
> with MooseX::IOC lately and thinking about what makes
> sense to push into a configuration for the purposes of
> being able to manage my applications more easily.

I used to work with Stevan on the application that spawned the
original IOC, so I've seen several apps which were fully IOC'ed.
Frankly, they're ugly and hard to work with. The problem isn't when
you're dealing with several cookie-cutter applications. IOC is an
adequate, if naive, solution to that type of problem. The problem is
when you want to tweak things. You either end up tweaking in your IOC
conf files (code in conf BAD!) or you have situations where you have a
file that just has tweaks to code that is auto-generated. This is
really really bad for people who don't work on that auto-generated
code day-in-day-out.

A better solution for cookie-cutter apps is to treat the differences
as configuration and run off the same code - just because your
application has a different userland name doesn't mean that the code
files need to have different classnames. So, if you truly have
cookie-cutter tables, then use the same tables, just in different
databases. Identically-structured databases for different applications
isn't  a bad thing. If you have different tables for storing different
kinds of information, then what are you doing trying to put your
schema into a conf file?

> To be honest I'm on the wall with this particular
> idea, which is why I thought to ask the group for
> thoughts.
>
> I have a similar idea which honestly makes more sense
> to me, which is to have a quick system to call
> $schema->populate against a configuration file.  This
> is actually quite easy to do, particularly now with
> the new multi create logic.  Then my database deploy
> scripts and tests can be easy to configure.

You want fixtures here. I've got a poor-man's fixtures cribbed from
Ruby's ActiveRecord stuff - I could throw it to the list and someone
take it and fold it in. Anyone interested?

> Another thing I was thinking this would make easier is
> that the configuration files would be a little more
> portable for different applications.  I already have
> several apps with a basic membership system which I
> typically just copy the classes.  Of course then I
> have to edit them to change the package names.  I
> guess you could just as easily do this with a Perl one
> liner so maybe that's not a particularly strong use
> case either.

See above - use the same classes against the same schema - just point
at different databases.

> There's been a push at my current job to move more
> stuff into configuration and out of code.  Sometimes
> it makes sense, other times it doesn't.

Schema should never be in conf. Configuration is what differs between
app instance A and app instance B. That's things like directory roots
and database user/pass. Unless, of course, you're treating DBIC as
purely a DBI overlay and not a true model. In which case, you're just
going to ignore me (and rightly so). :-)

Rob