Peter Rabbitson wrote:
David Ihnen wrote:
Ivan Fomichev wrote:
Hello, great module. Instead of arguing if it is a useful patch or not
and if it should be applied or there are weird workarounds easily
available, just make your own DBIx::Class component and release it on
CPAN. Who need
On Tue, Jun 30, 2009 at 11:14, David Ihnendav...@norchemlab.com wrote:
But the question seemed to be 'I don't understand why you would need this'
and 'is there a need for this feature' and I must vociferously respond IT
IS USEFULE and YES THERE IS. As for 'is there a need to do it this way'
David Ihnen wrote:
Peter Rabbitson wrote:
David Ihnen wrote:
Ivan Fomichev wrote:
Hello, great module. Instead of arguing if it is a useful patch or not
and if it should be applied or there are weird workarounds easily
available, just make your own DBIx::Class component and release
Rob Kinyon wrote:
Now, if someone can provide a solid use-case, then I'll be onboard.
But, adding features for the sake of adding features is how you end up
with a crappy API.
Rob
Lets see if I can argue the use case. I tripped over this limitation
and I *think* it was when I was doing this
Am 30.06.2009 um 18:10 schrieb David Ihnen:
Rob Kinyon wrote:
Now, if someone can provide a solid use-case, then I'll be onboard.
But, adding features for the sake of adding features is how you end
up
with a crappy API.
Rob
Lets see if I can argue the use case. I tripped over this
Rob Kinyon wrote:
On Wed, Jun 10, 2009 at 16:23, Daniel Ruosodan...@ruoso.com wrote:
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
On Mon, Jun 29, 2009 at 10:13, Peter Rabbitsonrabbit+d...@rabbit.us wrote:
A classical use-case is right side condition on a left-join. There is
no way to emulate those appropriately with WHERE - the condition has to
reside in the join spec itself: i.e. you need to get ALL artists, and
all cds
Rob Kinyon wrote:
On Mon, Jun 29, 2009 at 10:13, Peter Rabbitsonrabbit+d...@rabbit.us wrote:
A classical use-case is right side condition on a left-join. There is
no way to emulate those appropriately with WHERE - the condition has to
reside in the join spec itself: i.e. you need to get ALL
On Mon, Jun 29, 2009 at 19:43, David Ihnendav...@norchemlab.com wrote:
Rob Kinyon wrote:
On Mon, Jun 29, 2009 at 10:13, Peter Rabbitsonrabbit+d...@rabbit.us wrote:
A classical use-case is right side condition on a left-join. There is
no way to emulate those appropriately with WHERE - the
Hello, great module. Instead of arguing if it is a useful patch or not
and if it should be applied or there are weird workarounds easily
available, just make your own DBIx::Class component and release it on
CPAN. Who need will load this component. Good luck. Ivan.
Ivan Fomichev wrote:
Hello, great module. Instead of arguing if it is a useful patch or not
and if it should be applied or there are weird workarounds easily
available, just make your own DBIx::Class component and release it on
CPAN. Who need will load this component. Good luck. Ivan.
Can
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...
As I say in [1], as soon as a
Daniel Ruoso wrote:
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
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:
14 matches
Mail list logo
