On 2008-03-12 00:02:56 +0100, Zbigniew Lukasiak wrote:
> OK - with help from mst I've added another test testing that branch
> of the if statement - attached.
This is (finally) applied. Sorry for the long delay.
--
Daniel Westermann-Clark
___
List: h
On Sun, Mar 9, 2008 at 4:31 PM, Zbigniew Lukasiak <[EMAIL PROTECTED]> wrote:
> On Sat, Mar 8, 2008 at 9:24 PM, Daniel Westermann-Clark <[EMAIL PROTECTED]>
> wrote:
>
> >
> > Overall I think it's a sensible change, but it does bypass the
> > verification in _unique_queries of the number of Res
On Sat, Mar 8, 2008 at 9:24 PM, Daniel Westermann-Clark <[EMAIL PROTECTED]>
wrote:
>
> Overall I think it's a sensible change, but it does bypass the
> verification in _unique_queries of the number of ResultSet and query
> columns.
>
> Given that the logic looks cleaner this way, I'm inclined
On 2008-03-08 16:05:38 +, Matt S Trout wrote:
> DWC, PING. If this looks good for you I want it for 0.08100
Sorry for the delay. $job is not allowing me to spend time on open
source recently.
> > > > Also, shouldn't you ignore @unique_queries altogether if
> > > > you've got a key attr or am
DWC, PING. If this looks good for you I want it for 0.08100
On Tue, Feb 19, 2008 at 01:58:29AM +0100, Zbigniew Lukasiak wrote:
> On Feb 18, 2008 12:57 PM, Zbigniew Lukasiak <[EMAIL PROTECTED]> wrote:
> > On Feb 17, 2008 5:03 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> > > > >
> > > > > Looks go
On Feb 18, 2008 12:57 PM, Zbigniew Lukasiak <[EMAIL PROTECTED]> wrote:
> On Feb 17, 2008 5:03 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Looks good. Fancy doing the warn-if-more-than-one-result bit while
> > > > you're
> > > > in there as well?
> > >
> > > Attached. I think it
On Feb 18, 2008 6:10 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> On Mon, Feb 18, 2008 at 01:36:08PM +0100, Zbigniew Lukasiak wrote:
> > On Feb 17, 2008 4:58 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> > > >
> > > > Now, waiting for this to be committed, here is the problem with the
> > > > *_or
On Mon, Feb 18, 2008 at 01:36:08PM +0100, Zbigniew Lukasiak wrote:
> On Feb 17, 2008 4:58 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> > >
> > > Now, waiting for this to be committed, here is the problem with the
> > > *_or_* methods: Pg will not accept an INSERT with the primary key set
> > > to
On Feb 17, 2008 4:58 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> >
> > Now, waiting for this to be committed, here is the problem with the
> > *_or_* methods: Pg will not accept an INSERT with the primary key set
> > to NULL and on the other hand the "find" method will not accept a
> > query with
On Feb 17, 2008 5:03 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> > >
> > > Looks good. Fancy doing the warn-if-more-than-one-result bit while you're
> > > in there as well?
> >
> > Attached. I think it could even croak in that case.
>
> Your patch seems to bypass using $rs->single, which is a
On Thu, Feb 14, 2008 at 10:47:06PM +0100, Zbigniew Lukasiak wrote:
> On Thu, Feb 14, 2008 at 3:04 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, Feb 13, 2008 at 08:31:42PM +0100, Zbigniew Lukasiak wrote:
> > > On Feb 13, 2008 5:51 PM, Guillermo Roditi <[EMAIL PROTECTED]> wrote:
> > >
On Sun, Feb 17, 2008 at 02:14:16PM +0100, Zbigniew Lukasiak wrote:
> On Feb 14, 2008 10:47 PM, Zbigniew Lukasiak <[EMAIL PROTECTED]> wrote:
> > On Thu, Feb 14, 2008 at 3:04 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> > >
> > > On Wed, Feb 13, 2008 at 08:31:42PM +0100, Zbigniew Lukasiak wrote:
> >
On Feb 14, 2008 10:47 PM, Zbigniew Lukasiak <[EMAIL PROTECTED]> wrote:
> On Thu, Feb 14, 2008 at 3:04 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> >
> > On Wed, Feb 13, 2008 at 08:31:42PM +0100, Zbigniew Lukasiak wrote:
> > > On Feb 13, 2008 5:51 PM, Guillermo Roditi <[EMAIL PROTECTED]> wrote:
>
On Thu, Feb 14, 2008 at 3:04 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
>
> On Wed, Feb 13, 2008 at 08:31:42PM +0100, Zbigniew Lukasiak wrote:
> > On Feb 13, 2008 5:51 PM, Guillermo Roditi <[EMAIL PROTECTED]> wrote:
> > > > I attach a patch (against
> > > > http://dev.catalyst.perl.org/repos/ba
On Wed, Feb 13, 2008 at 08:31:42PM +0100, Zbigniew Lukasiak wrote:
> On Feb 13, 2008 5:51 PM, Guillermo Roditi <[EMAIL PROTECTED]> wrote:
> > > I attach a patch (against
> > > http://dev.catalyst.perl.org/repos/bast/DBIx-Class/0.08/trunk) that
> > > does more or less that - when you specify the uni
On Feb 13, 2008 5:51 PM, Guillermo Roditi <[EMAIL PROTECTED]> wrote:
> > I attach a patch (against
> > http://dev.catalyst.perl.org/repos/bast/DBIx-Class/0.08/trunk) that
> > does more or less that - when you specify the unique key it ignores
> > all columns from the query that don't belong to it (
> I attach a patch (against
> http://dev.catalyst.perl.org/repos/bast/DBIx-Class/0.08/trunk) that
> does more or less that - when you specify the unique key it ignores
> all columns from the query that don't belong to it (
I find this to be desired behavior Zbigniew Lukasiak++
___
On Feb 2, 2008 7:31 AM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> On Fri, Feb 01, 2008 at 05:11:19PM -0500, Daniel Westermann-Clark wrote:
> > On 2008-02-01 10:23:33 +0100, Zbigniew Lukasiak wrote:
> > > Yes - just ignore any column that is not part of the key in any case
> > > and then return the
> So
>
> $photos->search({ owned_by => $uid })->find({ id => $photo_id })
>
> has to include the WHERE owned_by = $uid even if the find specifies
> key => 'primary'.
>
> However, we -can- ignore keys passed in the find hash. But I'm not sure
> we should, except in case of a *_or_* call.
>
> Thought
On Feb 2, 2008 8:27 AM, Matt S Trout <[EMAIL PROTECTED]> wrote:
>
> On Sat, Feb 02, 2008 at 07:14:09AM +0100, Zbigniew Lukasiak wrote:
> > Hi Matt,
> >
> > Will I hear a 'thank you' from you? I mean I've spotted the bug, sent
> > test cases, analyzed the code and tried to explain how it happened
>
On Feb 2, 2008 8:27 AM, Matt S Trout <[EMAIL PROTECTED]> wrote:
>
> On Sat, Feb 02, 2008 at 07:14:09AM +0100, Zbigniew Lukasiak wrote:
> > Hi Matt,
> >
> > Will I hear a 'thank you' from you? I mean I've spotted the bug, sent
> > test cases, analyzed the code and tried to explain how it happened
>
On Fri, Feb 01, 2008 at 05:11:19PM -0500, Daniel Westermann-Clark wrote:
> On 2008-02-01 10:23:33 +0100, Zbigniew Lukasiak wrote:
> > Yes - just ignore any column that is not part of the key in any case
> > and then return the first row returned by the query.
>
> This does mean we'll break some sm
* On Sat, Feb 02 2008, Zbigniew Lukasiak wrote:
> How dare I? How a mere luser dare to have remarks that require
> intellectual effort from a code god like you?
Does this sort of commentary really help the project? Things work out
better when you relax and don't get too invested in your patch.
On Sat, Feb 02, 2008 at 07:14:09AM +0100, Zbigniew Lukasiak wrote:
> Hi Matt,
>
> Will I hear a 'thank you' from you? I mean I've spotted the bug, sent
> test cases, analyzed the code and tried to explain how it happened
> (perhaps that was not a good explanation - but a gifted programmer as
> yo
Hi Matt,
Will I hear a 'thank you' from you? I mean I've spotted the bug, sent
test cases, analyzed the code and tried to explain how it happened
(perhaps that was not a good explanation - but a gifted programmer as
you should be capable of analyzing the code directly without my help),
and your a
On 2008-02-01 10:23:33 +0100, Zbigniew Lukasiak wrote:
> Yes - just ignore any column that is not part of the key in any case
> and then return the first row returned by the query.
This does mean we'll break some small amount of back compat, though
the people specifying a 'key' attr probably aren'
On Feb 1, 2008 9:31 AM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> On Thu, Jan 31, 2008 at 11:09:19AM +0100, Zbigniew Lukasiak wrote:
>
> > On Jan 31, 2008 10:39 AM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> > > On Wed, Jan 30, 2008 at 07:57:02PM +0100, Zbigniew Lukasiak wrote:
> > > > Hi Matt,
> >
On Thu, Jan 31, 2008 at 11:09:19AM +0100, Zbigniew Lukasiak wrote:
> On Jan 31, 2008 10:39 AM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> > On Wed, Jan 30, 2008 at 07:57:02PM +0100, Zbigniew Lukasiak wrote:
> > > Hi Matt,
> > >
> > > You are a mystery to me - but I'll try to comply and interleave my
On Wed, Jan 30, 2008 at 07:57:02PM +0100, Zbigniew Lukasiak wrote:
> Hi Matt,
>
> You are a mystery to me - but I'll try to comply and interleave my
> comments with your original post as you wish.
>
> On Jan 24, 2008 1:14 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> > =head1 calling cases
> >
>
On Thu, Jan 31, 2008 at 11:09:19AM +0100, Zbigniew Lukasiak wrote:
> On Jan 31, 2008 10:39 AM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> > On Wed, Jan 30, 2008 at 07:57:02PM +0100, Zbigniew Lukasiak wrote:
> > > Hi Matt,
> > >
> > > You are a mystery to me - but I'll try to comply and interleave my
On Jan 31, 2008 10:39 AM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> On Wed, Jan 30, 2008 at 07:57:02PM +0100, Zbigniew Lukasiak wrote:
> > Hi Matt,
> >
> > You are a mystery to me - but I'll try to comply and interleave my
> > comments with your original post as you wish.
> >
> > On Jan 24, 2008 1:
On Wed, Jan 30, 2008 at 07:57:02PM +0100, Zbigniew Lukasiak wrote:
> Hi Matt,
>
> You are a mystery to me - but I'll try to comply and interleave my
> comments with your original post as you wish.
>
> On Jan 24, 2008 1:14 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> > =head1 calling cases
> >
>
Hi Matt,
You are a mystery to me - but I'll try to comply and interleave my
comments with your original post as you wish.
On Jan 24, 2008 1:14 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> =head1 calling cases
>
> Case 1 - called with 'key' attr and all columns for that key[0]
> Case 2 - called w
On Mon, Jan 28, 2008 at 05:19:22PM +0100, Zbigniew Lukasiak wrote:
> On Jan 28, 2008 4:43 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> > And this time reply to the original message as requested.
>
> I think
But evidently you don't read.
I've asked you politely several times now.
I've now had e
On Jan 28, 2008 5:19 PM, Zbigniew Lukasiak <[EMAIL PROTECTED]> wrote:
>
> On Jan 28, 2008 4:43 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> > On Fri, Jan 25, 2008 at 05:10:07PM +0100, Zbigniew Lukasiak wrote:
> > > On Jan 25, 2008 2:30 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> > > > On Fri, Ja
On Jan 28, 2008 4:43 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 25, 2008 at 05:10:07PM +0100, Zbigniew Lukasiak wrote:
> > On Jan 25, 2008 2:30 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> > > On Fri, Jan 25, 2008 at 12:24:27PM +0100, Zbigniew Lukasiak wrote:
> > > > Let me sidestep
On Fri, Jan 25, 2008 at 05:10:07PM +0100, Zbigniew Lukasiak wrote:
> On Jan 25, 2008 2:30 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> > On Fri, Jan 25, 2008 at 12:24:27PM +0100, Zbigniew Lukasiak wrote:
> > > Let me sidestep that a bit
> >
> > No, I won't let you.
> >
> > I spent an hour discussi
On Jan 25, 2008 5:10 PM, Zbigniew Lukasiak <[EMAIL PROTECTED]> wrote:
> On Jan 25, 2008 2:30 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> > On Fri, Jan 25, 2008 at 12:24:27PM +0100, Zbigniew Lukasiak wrote:
> > > Let me sidestep that a bit
> >
> > No, I won't let you.
> >
> > I spent an hour discu
On Jan 25, 2008 2:30 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> On Fri, Jan 25, 2008 at 12:24:27PM +0100, Zbigniew Lukasiak wrote:
> > Let me sidestep that a bit
>
> No, I won't let you.
>
> I spent an hour discussing with people how to structure this discussion so
> we can actually work out how
On Fri, Jan 25, 2008 at 12:24:27PM +0100, Zbigniew Lukasiak wrote:
> Let me sidestep that a bit
No, I won't let you.
I spent an hour discussing with people how to structure this discussion so
we can actually work out how to proceed in a framework that's clear, precise
and reasonably easy to conve
On Jan 24, 2008 1:14 PM, Matt S Trout <[EMAIL PROTECTED]> wrote:
> =head1 calling cases
>
> Case 1 - called with 'key' attr and all columns for that key[0]
> Case 2 - called with 'key' attr and not all columns for that key
>
> Case 3 - called without 'key' attr and with a unique key's worth of cols
=head1 calling cases
Case 1 - called with 'key' attr and all columns for that key[0]
Case 2 - called with 'key' attr and not all columns for that key
Case 3 - called without 'key' attr and with a unique key's worth of cols[0]
Case 4 - called without key and no unique set of columns
=head1 08000
42 matches
Mail list logo
