[Dbix-class] DBIC usage smoke/sanity check

[Ben Tilly]

What I personally did at a previous job was to write a job that would
take a SQL schema, create database tables, dump them to classes, etc.
And If I needed to make a database change we would absolutely load the
tables into a temporary database, compare with the real database, and
use SQL::Translator to make a diff.

One of the tricks that I found invaluable for that was that I had some
extra tables to keep track of documentation of fields, and to mark
some tables as being "part of the schema".  This mechanism is now
built in to DBIx::Class::Schema::Loader::Base.  Also
filter_generated_code (from the same module) is very, very useful.
For a start you probably want to use it to sqltidy the generated
classes to fit your style standards.

It was quite a bit of work.  And there were a lot of bugs on the way
to that solution.  But once it was up and running, I think it worked
pretty well.

Yes, I know that a lot of developers just code in DBIx::Class.
However then you're limited to a lowest common denominator.  Key
database information, such as what indexes you need and full details
on some data types, can't be emitted by DBIx::Class, or survive a trip
through it.  That is why I wound up settling for having the canonical
form be SQL, and then everything is generated off of that.  (And, of
course, you can add custom methods after the autogenerated bit.)

On Tue, Dec 18, 2012 at 1:59 PM, Bill Moseley <moseley at hank.org> wrote:
>
>
> On Tue, Dec 18, 2012 at 12:20 AM, Peter Rabbitson <rabbit+dbic at rabbit.us>
> wrote:
>>
>> On Sat, Dec 15, 2012 at 10:05:07AM -0800, Bill Moseley wrote:
>> > I've been asked to add something to our build process that does some
>> > kind
>> > of sanity check on the database.   For example, make sure all columns
>> > defined in the result class exist in the target database.
>> >
>> > I realize this won't catch every potential problem, but should catch
>> > missing columns (or tables) which is our biggest risk.
>> >
>> > This seems like a reasonable way to do this?
>>
>> I personally would opt for an in-memory DBIC::Schema::Loader dump, and
>> then running comparisons between the corresponding resultsource instances.
>> A little bit more work- but much more robust.
>
>
> Our sources were created by hand, so I doubt the dump would match.    But,
> maybe that's a good reason to update our sources.   We have been pretty lazy
> and not defining that many attributes on our columns.
>
>
> --
> Bill Moseley
> moseley at hank.org
>
> _______________________________________________
> List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
> IRC: irc.perl.org#dbix-class
> SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
> Searchable Archive:
> http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk