Em Dom, 2009-06-21 às 13:57 +0200, Peter Rabbitson escreveu:
> Daniel Ruoso wrote:
> > Using scalar ref to allow arbitrary SQL is consistent with SQLA, since
> > you can use it in regular SQLA where data structures, so I think it's
> > not really weak or incomplete...
>
Em Sex, 2009-06-19 às 13:36 +0100, Pedro Melo escreveu:
> > Em Qui, 2009-06-18 às 13:18 +0100, Pedro Melo escreveu:
> >> I'm wrapping DBIx::Class over a legacy database that uses the
> >> iso-8859-1 charset internally. My app expects all perl strings as
> >> utf8.
> > I think you could consider c
Em Qui, 2009-06-18 às 13:18 +0100, Pedro Melo escreveu:
> I'm wrapping DBIx::Class over a legacy database that uses the
> iso-8859-1 charset internally. My app expects all perl strings as utf8.
I think you could consider changing the encoding of the DB connection,
before trying to do that as inf
Em Qui, 2009-06-11 às 13:10 +0200, Peter Rabbitson escreveu:
> It would be much better to introduce real arbitrary support via SQLA
> where condition parsing. Only real problem is that a hashref is already
> resrved for foreign./self. pairs, and what's even worse - it recently
> started taking sing
Hi,
For some reason this patch is sitting on my local git copy for a while,
and now I'm not sure it was even sent at some point... /me--
So, here goes a patch against current 0.08 trunk to support arbitrary
SQL in the join condition with an included test, which allow something
like:
__PACKAGE__-
Hi,
I'm working on an application that have the following classes:
TaskType --- has_many ---> TaskTypeFile
but, that can actually be seen as two relationship types:
has_many { type => input } __
/ \
TaskType
