[Dbix-class] DBIx::Class::Loader 0.18 released

[Brandon Black]

On 2/4/06, Alex Kavanagh <alex at tinwood.homelinux.org> wrote:
> Brandon Black wrote:
> > DBIx-Class-Schema-Loader is now at version 0.01002 on CPAN, and it
> > seems like it should work for most people.  Please give it a shot.
> > The transition could be rough for some, as some Loader users are
> > probably using Loader-isms in their DBIx::Class code that will need to
> > be changed to Schema-isms.  By 0.02 I expect it to be fairly stable,
> > other than future feature additions for obtaining better metadata and
> > building smarter relationships.
>
> Okay, I'd like to try to switch.  I'm using it with Catalyst which
> I've only just started using and therefore I don't really know whether
> I'm using bad DBIx::Class usage habits.
>
> Is there a tutorial or some info on how to switch from D::C::L to
> D::C::S::L ??
>

No, there's no such tutorial at this time, although perhaps there
should be a guide of sorts.

The problem can really be divided into two parts.  Firstly, even with
older versions of DBIx::Class and DBIx::Class::Loader, some people are
unwittingly using loader-specific methods and not realizing it.  For
instance, I was using My::DB->table('foo_table')->search() all over
the place in my code.  That usage of ->table('foo_table') is a
Loader-ism.  Even at the time, converting off of ::Loader to a
manually-defined DBIx::Class would have meant eliminating that usage.

Secondly, there's the differences between the old DB-based way of
using DBIx::Class, and the new Schema way.  The old DB-way still works
for manual users of DBIx::Class, or users of DBIx::Class::Loader
against newer DBIx::Class, but I don't believe it quite works for
using ::Schema::Loader, seeing as the entire definition is done in the
Schema way, not the DB way.

In the DB way, it was possible to do things like
My::DB::FooTable->search();

Whereas in the Schema way, this should be written:
$myschema->resultset('foo_table')->search();

Even in pre-0.05 DBIx::Class, the first method using statically
defined Table-class names was unwise, but it just worked.  It still
works if your database and table classes are defined the DB-way, just
not if they're defined in the newer/better Schema way of doing things.
 The new Schema::Loader defines them in the Schema way, so...

Someone who was using DBIx::Class::Loader and then usage patterns like
MyDB->table('foo')->search()

or
MyDB::Foo->search()

will need to switch to:
$myschema->resultset('foo')->search()

Technically you can also do:
My::Schema->resultset('foo')->search() on a connected schema-class,
but it's probably unwise as you'll have to go back and make them
object methods if you ever want to use multiple connections at the
same time within the same perl execution environment (for instance, if
this code is in a mod_perl app, and multiple instances of this app
with seperate databases are expected to run in a single apache
server).

There are also loader-specific mechanisms in a Schema generated by
DBIx::Class::Schema::Loader, which should be avoided if you ever might
move off of Schema::Loader to manually defining your Schema.  However,
it's rather difficult to not realize you're using them, as they are
all accessed via $myschema->loader, like $myschema->loader->tables;
$myschema->loader->monikers; etc.

When/if you convert off od Schema::Loader, $myschema->loader is the
only thing that will cease to exist.  Everything else should work the
same regardless of whether you're using ::Schema::Loader or a
manually-defined Schema.

-- Brandon