[Dbix-class] Schema::Loader and views on Pg

Matt S Trout mst at shadowcat.co.uk
Thu May 6 20:28:23 GMT 2010


On Sun, May 02, 2010 at 09:56:15PM -0700, Dorian Taylor (Lists) wrote:
> 
> On 2-May-10, at 12:59 PM, Matt S Trout wrote:
> Thanks!
> 
> >What about letting S::L pull the column names and then just setting  
> >the
> >primary keys and adding rels as a fixup?
> 
> I think what I'm going to do is make the current views into tables and  
> then use triggers on the database (probably rules actually, then I  
> don't have to go faffing around with plsql) to append to the logs when  
> I update. That'll probably perform better in the long run anyway.

Ahaha. Ahahahahahahaha.

Don't use rules.

If you do, just use them to call a sproc.

But really, use a trigger.

Rules except as a means to emulate triggers on a writable view are almost
never what you want. Several of the serious pg consultants on freenode
#postgresql have a standing challenge to show a non-trivial rule that isn't
buggy. I've never seen it won, and I at least -understand- the rule system
which most people don't (it's a lisp-style query tree rewrite which is where
the fun comes in - things like currval ain't reliable).
 
> In that case, is there a "read-only" base class kicking around to make  
> it easier to diagnose errant updates (e.g. by croaking when you try to  
> use a mutator instead of waiting for the database to reject it with an  
> ACL)?

You could overload register_column to generate readonly accessors.

sub update { die "Bad developer. No cookie." }

might be just as effective.
 
> >Note that once you've got $other_class loaded you can always do
> >
> >my $source = My::Schema::Foo->result_source_instance;
> >
> >and then pull the relationships straight out of the main foo source.
> >
> >See the code in
> >
> >git://git.shadowcat.co.uk/dbsrights/DBIx-Class-ResultSource- 
> >MultipleTableInheritance.git
> >
> >for some interesting Pg madness with views and result source  
> >introspection
> >(also, mad props to Amiri Barksdale for documenting the thing for me  
> >- just
> >waiting for a couple more people to say "yes it works" and I'll see  
> >about
> >shipping it to CPAN)
> 
> Tempting, but probably opening a can of worms with versions/deployment  
> etc. Would prefer to stick to CPAN.

Dammit, I'm saying "if it works for you I'll CPAN it".

I'm just trying to make sure at least one human being who didn't write
either the code or the docs has used it first.

Pretty please? If it makes you happy I could ship 0.001_001 to CPAN as a dev
release and you can install it from there instead :)

> Hmm, is there a way to get Schema::Loader to append arbitrary code to  
> a selection of the files it generates? like
> 
> make_schema_at(append_code => sub {
>     my $table = shift;
>     return unless $TABLES{$table};
>     my $code = generate_extra_code_for($table);
>     return $code;
>  }); ?

There's probably a relevant bit of Schema::Loader to subclass?

Once you start getting this clever I tend to vote for switching to writing
the result classes and using DBIx::Class::Schema::Versioned to produce the
database for you, or at least the basics of it.

If nothing else, you might want to look at MultipleTableInheritance.git as
the only (to my knowledge) extant example of generating functions as well as
a view from a single resultsource.

-- 
Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue

http://shadowcat.co.uk/blog/matt-s-trout/   http://twitter.com/shadowcat_mst/

Email me now on mst (at) shadowcat.co.uk and let's chat about how our Catalyst
commercial support, training and consultancy packages could help your team.



More information about the DBIx-Class mailing list