[Dbix-class] newbie questions on development practices

[Matt S Trout]

On Fri, Jun 22, 2007 at 11:24:28AM -0700, john edstrom wrote:
> hi,
> 
> I'm just getting started and have a couple questions.
> 
> 1) I began with a simple set of tables & relations (see attached
> diagram).  
> 
> I created the initial class description from what I read in the
> documentation and used SQL::Translator to build SQL files to create the
> tables & stuff.
> 
> It got everything right except the foreign key linking users.uid to
> thing.thid.  It just wouldn't do it no matter what I tried
> (belongs_to,might_have,etc) it just wouldn't generate a foreign key
> there.

That works perfectly for a lot of people; if you could show me the schema
and the resulting .sql file and make sure you've got the latest SQLT then
we could maybe try and fix that.

This is what I do for any greenfield project and against MySQL and Pg it
works fine.

> My question is, what's the 'best practice' here for ginning up a new
> project?  Craft the tables by hand (or 3rd party tool), infer it with
> the schema loader and use the inferred classes to work with?  Or is
> there a better way?

I prefer deploy; a lot of people prefer Schema::Loader static mode. It's a
matter of taste really; some people prefer S::L because they want to think
in relational terms when designing their schema and can't do that in terms
of the perl syntax, some prefer to think in terms of classes so use deploy,
and I'm odd in that I think in relational terms but still prefer deploy due
to DRY and the fact I can see the resulting schema in my head as I'm writing
out the perl code :) 
 
> 2) I created a view for a user-thing (basically a user as a subclass of
> thing) with the usual joins and things.  
> 
> The schema loader saw it and captured the structure OK but didn't
> analyze the view any deeper (PostgreSQL 8.1, btw).  I didn't really
> expect it to, so I'm not complaining.
>
> But I can see how defining a complex search with DBIx might get gnarly
> as the project progresses and it occurred to me that if DBIx::Class
> could analyze views then it could use that as a sort of
> DBIx::Class::ResultSet definition, either to create a
> DBIx::Class::ResultSet definition file, or maybe employ a pre-existing
> view in searches.
> 
> Are there any plans for using views in DBIx in the future?

I use updatable views in pg a fair bit, but I just knock out the column
list into a DBIC class and set up the rels by hand; I don't consider the extra
typing a problem for the flexibility it buys me.

To be honest though, I'm more interested in figuring out how to make complex
query definitions less gnarly on the DBIC side and provide a means to deploy
those to DBs that support such than in finding a way to parse out view
definitions - that's in terms of things -I'd- likely work on though, I'd love
to see support for them added to Schema::Loader but it's not something I'd
use except as an initial slurp when I adopt a legacy database.

-- 
      Matt S Trout       Need help with your Catalyst or DBIx::Class project?
   Technical Director    Want a managed development or deployment platform?
 Shadowcat Systems Ltd.  Contact mst (at) shadowcatsystems.co.uk for a quote
http://chainsawblues.vox.com/             http://www.shadowcatsystems.co.uk/