[Dbix-class] (ping zby) Patch for SQL::Translator::Parser::DBIx::Class

[Matt S Trout]

Sebastian Willert wrote:
> On Mon, 2006-06-26 at 14:35 +0100, Matt S Trout wrote:
>> Sebastian Willert wrote:
>>> Actually, that was kind of my initial intention, after I ran into
>>> trouble using deploy(), which seems to need a run-time connection before
>>> being called. (Regarding your next post: the problems might have easily
>>> been caused by missing data_types in the schema, yes)
>> Well, that's what deploy() is *for* - deploying to the database you're 
>> connected to.
> 
> Yeah I know, the problem arises when you try to deploy to the database
> but have missing data_types. The SQLT::Parser::DBIC tries to read them
> from the table, which isn't in place yet and thus dies loudly (with
> 'Unknown table XXX', IIRC ), while the process keeps running because the
> call is wrapped in an eval{}. This is very confusing behaviour, and I'd
> rather have a 'No data_type for X has been found and could not be
> guessed from DB' kind of warning. Together with SQLite silently changing
> their binary format from 3.2 (my distros command-line tool) to 3.3
> (DBD::SQLites 1.12 internal one) and thus dumping the created DB yielded
> no generated tables at all (but no warning about incompatible file
> formats, whatsoever), I was under the impression that something in there
> was really wrong.

Right, which is fine as just a warning normally (although it could do with 
being a more descriptive warning, I'm sure) but during deploy lack of 
data_type etc. need to be a hard error.

We need to take a hard look at the way column_info auto-calls columns_info_for 
currently, since this is the root of the problem. Zby, any ideas?

-- 
      Matt S Trout       Offering custom development, consultancy and support
   Technical Director    contracts for Catalyst, DBIx::Class and BAST. Contact
Shadowcat Systems Ltd.  mst (at) shadowcatsystems.co.uk for more information

+ Help us build a better perl ORM: http://dbix-class.shadowcatsystems.co.uk/ +