[Dbix-class] Patch for SQL::Translator::Parser::DBIx::Class

Sebastian Willert willert at gmail.com
Mon Jun 26 15:18:05 CEST 2006


On Sun, 2006-06-25 at 21:32 +0100, Matt S Trout wrote:
> Sebastian Willert wrote:
> > On Sun, 2006-06-25 at 20:39 +0100, Matt S Trout wrote:
> >> Sebastian Willert wrote:
> > 
> > That depends on the intention of SQLT::Parser::DBIC, i think. If the
> > intention is to dump a running schema instance, then you are perfectly
> > correct. But if the intention is to build databases according to the
> > hard-coded info (i.e. the prototype) in the schema then relying on
> > run-time info gathered from a database is harmful IMO.
> 
> You're misunderstanding the nature of schema class versus schema instance, 
> though. There's no reason whatsoever why somebody might not construct a schema 
> object out of resultsources themselves for whatever reason - the class-based 
> setup normally used is strictly convenience syntax, not anything key to the 
> nature of the system. Hence DBIx::Class::DB simply creates a 
> DBIx::Class::Schema object and stores it as class data on the base class, 
> registering sources against the object as the classes are loaded. While DB is 
> deprecated, the use of schema objects this way is perfectly allowed, and your 
> patch would break that (since it would require the sources to have been 
> registered against the DBIx::Class::Schema class itself).

OK, I see the point. Thanks for the exhaustive explanation.

>  > If I was wrong, I'll happily retract my patch, though.
> 
> I'm not sure I see the point; if you don't want run-time connected info, don't 
> hand SQLT a connected schema. A documentation patch pointing this out would 
> seem far more useful to me.

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)

If this is the case, the correct approach would be to warn (or even
die?) in SQLT::Parser::DBIC in a situation where data_type is unknown
and no table information can be retrieved? And some docs regarding
SQLT::Parser::DBIC, DBIC::Schema::deploy() and about testing schemas in
general?

I think I could try to do some of this, but I've seen that my
understanding of DBIC still sucks, so I am not very confident :(

Cheers,
  Sebastian




More information about the Dbix-class mailing list