Hrrm, I look away for a few days, and the list wakes up.. I should use a
better mail client...
Anyway, on the subject:
As Matt said, we've now got a DBIx::Class parser, which creates SQLT
schemas from a loaded DBIx::Class Schema, and a producer which spits out
an all-in-one DBIx::Class schema definition file. Theres no
create-in-memory one yet, but will be when I figure out how ;)
Having done this, Ive realised SQLT is a bit self-contained about some
things it maybe shouldnt be, for example, all the parser and producer args
are stuck in the "sqlt" script, which means if I write an external
parser/producer, and want a new arg, I have to hack SQLT files.
Any objection to me attempting to make SQLT allow the Parsers/Producers
define their required arguments, and the "sqlt" script query them? (via
SQL::Translator->parser, when it sets which parser we're using, etc,
maybe?) It would also need to query them when outputting the "usage"
This would presumably be needed it we start splitting SQLT into bits
hmm, there was something else, but Ive forgotten what it was..
On Tue, 31 Jan 2006, Matt S Trout wrote:
> On Mon, Jan 30, 2006 at 08:58:51PM -0600, Ken Youens-Clark wrote:
> > On Oct 15, 2005, at 5:47 AM, Paul Makepeace wrote:
> > >I'm looking into creating a DBIx::Class producer. Is anyone working on
> > >this already? One thing I noted when using the Class::DBI producer was
> > >that there could very usefully be a base class specifier on the sqlt
> > >command line - OK to do that too?
> > OK, first off, have I really not checked in on SQLT mail since
> > October? I stink. Sorry. I have had another kid since then, but,
> > jeez, that only goes so far!
> > Anyway, I don't believe anyone has worked on a DBIx::Class producer,
> > but I'd be very interested in seeing one. I've been doing a lot
> > lately with Class::DBI, and I like it but can see it's drawbacks.
> > I've actually rolled my own CDBI producer (some Perl plus a TT
> > template) that I'm going to float in updating our CDBI producer, and
> > I might add the work I did on an SPOPS producer. The more code
> > generators the better!
> Jess Robinson has written both parsers and producers; due to the slow
> release cycle of SQL::Translator compared to DBIx::Class we've rolled them
> into DBIx::Class instead; the latest dev release on CPAN (0.04999_06)
> contains them and they'll go "public" when 0.05 ships (hopefully this week)
> 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/ +
> This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
> for problems? Stop! Download the new AJAX search engine that makes
> searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
> sqlfairy-developers mailing list