[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