[Dbix-class] DBIx::Class::Schema::Loader limitations

Daniel McBrearty danielmcbrearty at gmail.com
Thu Jun 29 21:29:41 CEST 2006


and seeing the docs for Loader::Base ... it looks like {relationships
=> 1} gives 1-1 and 1-many but not many-many relationships. so maybe
that's the better reason for manual definition ... ?

Also it actually looks like 'deploy' is still billed as experimental.
Is this just outdated documentation, or for real? Are people actually
using this on production code? Is the idea to get the schema
definition and the app all into the same code base? If so, you
presumably have to dump all of your data, drop the old db, use
'deploy', and restore data in the case of a code update involving a
schema change. Does this really work reliably for all cases?

My current conception of how to do this is just to make schema update
scripts ("alter table ...") to go with code updates.

Sorry for so many q's, but it's just not clear to me what "best
practice" is here, or what the real pros and cons of adopting a
particular way of working is.


On 6/29/06, Daniel McBrearty <danielmcbrearty at gmail.com> wrote:
> Thanks. That has me thinking. I hadn't even considered the idea of
> defining the db in DBIC. The way we are working at the moment is
> indeed to write a db.sql file which defines the schema, then autoload
> it. We also use triggers and functions to check any constraints at the
> db level (ones that can't be covered by simple PK/unique statements).
> Then build on top of it.
>
> What do you do when you work the other way around, and you have
> constraints of this type? do you enforce them at the db level at all?
>
>
> On 6/29/06, Brandon Black <blblack at gmail.com> wrote:
> > On 6/29/06, Daniel McBrearty <danielmcbrearty at gmail.com> wrote:
> > > Or will Loader automatically
> > > detect and define realationships for us?
> >
> > Yes, you just have to supply the optional parameter "relationships =>
> > 1" (see perldoc DBIx::Class::Schema::Loader[::Base]), and it will load
> > up your relationships for you.
> >
> > > Is this the point where we should start manually defining
> > > relationships and throw away Loader?
> >
> > Especially if you're just now building your own database from scratch,
> > it really is best to build manual schemas and then deploy to your
> > rdbms via ->deploy, rather than the other way around (which is to
> > write SQL CREATE TABLE statements, deploy them manually, then use
> > Schema::Loader to create the schema).  The core arguments for the
> > former over the latter boil down to that DBIx::Class::Schema has more
> > metadata than your SQL DDL statements have, therefore it is the
> > preferred original source.
> >
> > The big use-case for the Loader in the first place is primarily people
> > attaching to legacy databases over which they have little control or
> > design input.
> >
> > An easy way to wean yourself is to use the new Schema::Loader feature
> > to dump the schema definition to a set of static class files, and then
> > take over manual maintenance from there (see the perldoc section on
> > "dump_to_dir" and "make_schema_at").  This functionality is a bit
> > clunky at the moment, but will eventually become a simple command in
> > the dbicadmin shell (or at least that's the plan).
> >
> > Of course, you're free to keep using Loader all you want forever, its
> > just probably not the best practice. in most peoples' situations.
> >
> > -- Brandon
> >
> > _______________________________________________
> > List: http://lists.rawmode.org/cgi-bin/mailman/listinfo/dbix-class
> > Wiki: http://dbix-class.shadowcatsystems.co.uk/
> > IRC: irc.perl.org#dbix-class
> > SVN: http://dev.catalyst.perl.org/repos/bast/trunk/DBIx-Class/
> > Searchable Archive: http://www.mail-archive.com/dbix-class@lists.rawmode.org/
> >
>
>
> --
> Daniel McBrearty
> email : danielmcbrearty at gmail.com
> www.engoi.com : the multi - language vocab trainer
> BTW : 0873928131
>


-- 
Daniel McBrearty
email : danielmcbrearty at gmail.com
www.engoi.com : the multi - language vocab trainer
BTW : 0873928131



More information about the Dbix-class mailing list