Mailing List Archive: Interchange: users

Long-lived co=1 bug

Index | Next | Previous | View Threaded

emailgrant at gmail

Oct 1, 2004, 1:47 PM

Post #1 of 9 (732 views)
Permalink

Long-lived co=1 bug

There has been a long-lived bug that doesn't allow something like this
to work properly:

[loop search="fi=orders/ml=999999/st=db/sf=shipment_notification_sent/se=1/op=ne/nu=0"]
[loop-data orders order_number]
[/loop]

Even though the shipment_notification_sent field is set to 1 for every
record in the table, this has a ton of output, maybe all the orders.
Adding co=1 fixes it, but this isn't a coordinated search.

I've reported this bug before, and someone told me it's a known bug.
I'm using IC 5.2. Is there any hope of this being fixed?

- Grant

racke at linuxia

Oct 1, 2004, 2:59 PM

Post #2 of 9 (713 views)
Permalink

Long-lived co=1 bug [In reply to]

On Fri, 1 Oct 2004 10:46:52 -0700
Grant <emailgrant [at] gmail> wrote:

> There has been a long-lived bug that doesn't allow something like this
> to work properly:
>
> [loop search="fi=orders/ml=999999/st=db/sf=shipment_notification_sent/se=1/op=ne/nu=0"]
> [loop-data orders order_number]
> [/loop]
>
> Even though the shipment_notification_sent field is set to 1 for every
> record in the table, this has a ton of output, maybe all the orders.
> Adding co=1 fixes it, but this isn't a coordinated search.
>
> I've reported this bug before, and someone told me it's a known bug.
> I'm using IC 5.2. Is there any hope of this being fixed?

At least it is weird behaviour and I don't like it as well. But I think we
need the expertise of Mike Heins who can tell us what would break if we
fix this somehow :-)

Bye
Racke

--
LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration
ICDEVGROUP => http://www.icdevgroup.org/
Interchange Development Team

emailgrant at gmail

Oct 1, 2004, 3:12 PM

Post #3 of 9 (708 views)
Permalink

Long-lived co=1 bug [In reply to]

> > There has been a long-lived bug that doesn't allow something like this
> > to work properly:
> >
> > [loop search="fi=orders/ml=999999/st=db/sf=shipment_notification_sent/se=1/op=ne/nu=0"]
> > [loop-data orders order_number]
> > [/loop]
> >
> > Even though the shipment_notification_sent field is set to 1 for every
> > record in the table, this has a ton of output, maybe all the orders.
> > Adding co=1 fixes it, but this isn't a coordinated search.
> >
> > I've reported this bug before, and someone told me it's a known bug.
> > I'm using IC 5.2. Is there any hope of this being fixed?
>
> At least it is weird behaviour and I don't like it as well. But I think we
> need the expertise of Mike Heins who can tell us what would break if we
> fix this somehow :-)
>
> Bye
> Racke

Hmmm, you're right. Fixing it would undoubtedly break many a catalog.
Maybe an interchange.cfg directive is in order?

FixCoBug 1

- Grant

emailgrant at gmail

Oct 1, 2004, 6:48 PM

Post #4 of 9 (703 views)
Permalink

Long-lived co=1 bug [In reply to]

> > > There has been a long-lived bug that doesn't allow something like this
> > > to work properly:
> > >
> > > [loop search="fi=orders/ml=999999/st=db/sf=shipment_notification_sent/se=1/op=ne/nu=0"]
> > > [loop-data orders order_number]
> > > [/loop]
> > >
> > > Even though the shipment_notification_sent field is set to 1 for every
> > > record in the table, this has a ton of output, maybe all the orders.
> > > Adding co=1 fixes it, but this isn't a coordinated search.
> > >
> > > I've reported this bug before, and someone told me it's a known bug.
> > > I'm using IC 5.2. Is there any hope of this being fixed?
> >
> > At least it is weird behaviour and I don't like it as well. But I think we
> > need the expertise of Mike Heins who can tell us what would break if we
> > fix this somehow :-)
> >
> > Bye
> > Racke

I'm having a hard time pinning this down so I know when I need to use
co=1 for a non-coordinated search. Does anyone know when that is
necessary?

- Grant

racke at linuxia

Oct 2, 2004, 4:41 AM

Post #5 of 9 (712 views)
Permalink

Long-lived co=1 bug [In reply to]

On Fri, 1 Oct 2004 15:48:18 -0700
Grant <emailgrant [at] gmail> wrote:

> > > > There has been a long-lived bug that doesn't allow something like this
> > > > to work properly:
> > > >
> > > > [loop search="fi=orders/ml=999999/st=db/sf=shipment_notification_sent/se=1/op=ne/nu=0"]
> > > > [loop-data orders order_number]
> > > > [/loop]
> > > >
> > > > Even though the shipment_notification_sent field is set to 1 for every
> > > > record in the table, this has a ton of output, maybe all the orders.
> > > > Adding co=1 fixes it, but this isn't a coordinated search.
> > > >
> > > > I've reported this bug before, and someone told me it's a known bug.
> > > > I'm using IC 5.2. Is there any hope of this being fixed?
> > >
> > > At least it is weird behaviour and I don't like it as well. But I think we
> > > need the expertise of Mike Heins who can tell us what would break if we
> > > fix this somehow :-)
> > >
> > > Bye
> > > Racke
>
> I'm having a hard time pinning this down so I know when I need to use
> co=1 for a non-coordinated search. Does anyone know when that is
> necessary?

I think if the op= parameter is given.

Bye
Racke

--
LinuXia Systems => http://www.linuxia.de/
Expert Interchange Consulting and System Administration
ICDEVGROUP => http://www.icdevgroup.org/
Interchange Development Team

emailgrant at gmail

Mar 10, 2010, 11:06 AM

Post #6 of 9 (707 views)
Permalink

Re: Long-lived co=1 bug [In reply to]

>> > > > There has been a long-lived bug that doesn't allow something like this
>> > > > to work properly:
>> > > >
>> > > > [loop search="fi=orders/ml=999999/st=db/sf=shipment_notification_sent/se=1/op=ne/nu=0"]
>> > > > [loop-data orders order_number]
>> > > > [/loop]
>> > > >
>> > > > Even though the shipment_notification_sent field is set to 1 for every
>> > > > record in the table, this has a ton of output, maybe all the orders.
>> > > > Adding co=1 fixes it, but this isn't a coordinated search.
>> > > >
>> > > > I've reported this bug before, and someone told me it's a known bug.
>> > > > I'm using IC 5.2. �Is there any hope of this being fixed?
>> > >
>> > > At least it is weird behaviour and I don't like it as well. But I think we
>> > > need the expertise of Mike Heins who can tell us what would break if we
>> > > fix this somehow :-)
>> > >
>> > > Bye
>> > > � � � � Racke
>>
>> I'm having a hard time pinning this down so I know when I need to use
>> co=1 for a non-coordinated search. �Does anyone know when that is
>> necessary?
>
> I think if the op= parameter is given.
>
> Bye
> � � � �Racke

About 5 1/2 years later, I think I've got this more nailed down.
Adding co=1 seems to be necessary unless there is only one sf/se block
and op=eq is in affect. Is this really a bug, or am I
misunderstanding mv_coordinate?

This document:

http://docs.icdevgroup.org/cgi-bin/online/search/search_reference.html

says:

"the so-called "coordinated" search allows for multiple search options
to be stacked on top of each other"

but it seems to be necessary even when there is only one sf/se block
unless using op=eq.

- Grant

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

emailgrant at gmail

May 20, 2012, 2:02 AM

Post #7 of 9 (226 views)
Permalink

Re: Long-lived co=1 bug [In reply to]

>>> > > > There has been a long-lived bug that doesn't allow something like this
>>> > > > to work properly:
>>> > > >
>>> > > > [loop search="fi=orders/ml=999999/st=db/sf=shipment_notification_sent/se=1/op=ne/nu=0"]
>>> > > > [loop-data orders order_number]
>>> > > > [/loop]
>>> > > >
>>> > > > Even though the shipment_notification_sent field is set to 1 for every
>>> > > > record in the table, this has a ton of output, maybe all the orders.
>>> > > > Adding co=1 fixes it, but this isn't a coordinated search.
>>> > > >
>>> > > > I've reported this bug before, and someone told me it's a known bug.
>>> > > > I'm using IC 5.2. �Is there any hope of this being fixed?
>>> > >
>>> > > At least it is weird behaviour and I don't like it as well. But I think we
>>> > > need the expertise of Mike Heins who can tell us what would break if we
>>> > > fix this somehow :-)
>>> > >
>>> > > Bye
>>> > > � � � � Racke
>>>
>>> I'm having a hard time pinning this down so I know when I need to use
>>> co=1 for a non-coordinated search. �Does anyone know when that is
>>> necessary?
>>
>> I think if the op= parameter is given.
>>
>> Bye
>> � � � �Racke
>
> About 5 1/2 years later, I think I've got this more nailed down.
> Adding co=1 seems to be necessary unless there is only one sf/se block
> and op=eq is in affect. �Is this really a bug, or am I
> misunderstanding mv_coordinate?
>
> This document:
>
> http://docs.icdevgroup.org/cgi-bin/online/search/search_reference.html
>
> says:
>
> "the so-called "coordinated" search allows for multiple search options
> to be stacked on top of each other"
>
> but it seems to be necessary even when there is only one sf/se block
> unless using op=eq.
>
> - Grant

The following search returns products in the category "Widgets" and
products in the category "Big Widgets":

[loop search="fi=products/st=db/sf=category/se=Widgets/op=eq/nu=0"][/loop]

If I add co=1, only "Widgets" are returned. According to the
documentation, co=1 "allows for multiple search options to be stacked
on top of each other". I reported some exceptions to this above, but
now I'm thinking co=1 should be used in all searches?

- Grant

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

josh at perusion

May 21, 2012, 7:51 AM

Post #8 of 9 (227 views)
Permalink

Re: Long-lived co=1 bug [In reply to]

Quoting Grant (emailgrant [at] gmail):
> >>> > > > There has been a long-lived bug that doesn't allow something like this
> >>> > > > to work properly:
> >>> > > >
> >>> > > > [loop search="fi=orders/ml=999999/st=db/sf=shipment_notification_sent/se=1/op=ne/nu=0"]
> >>> > > > [loop-data orders order_number]
> >>> > > > [/loop]
> >>> > > >
> >>> > > > Even though the shipment_notification_sent field is set to 1 for every
> >>> > > > record in the table, this has a ton of output, maybe all the orders.
> >>> > > > Adding co=1 fixes it, but this isn't a coordinated search.
> >>> > > >
> >>> > > > I've reported this bug before, and someone told me it's a known bug.
> >>> > > > I'm using IC 5.2. �Is there any hope of this being fixed?
> >>> > >
> >>> > > At least it is weird behaviour and I don't like it as well. But I think we
> >>> > > need the expertise of Mike Heins who can tell us what would break if we
> >>> > > fix this somehow :-)
> >>> > >
> >>> > > Bye
> >>> > > � � � � Racke
> >>>
> >>> I'm having a hard time pinning this down so I know when I need to use
> >>> co=1 for a non-coordinated search. �Does anyone know when that is
> >>> necessary?
> >>
> >> I think if the op= parameter is given.
> >>
> >> Bye
> >> � � � �Racke
> >
> > About 5 1/2 years later, I think I've got this more nailed down.
> > Adding co=1 seems to be necessary unless there is only one sf/se block
> > and op=eq is in affect. �Is this really a bug, or am I
> > misunderstanding mv_coordinate?
> >
> > This document:
> >
> > http://docs.icdevgroup.org/cgi-bin/online/search/search_reference.html
> >
> > says:
> >
> > "the so-called "coordinated" search allows for multiple search options
> > to be stacked on top of each other"
> >
> > but it seems to be necessary even when there is only one sf/se block
> > unless using op=eq.
> >
> > - Grant
>
> The following search returns products in the category "Widgets" and
> products in the category "Big Widgets":
>
> [loop search="fi=products/st=db/sf=category/se=Widgets/op=eq/nu=0"][/loop]
>
> If I add co=1, only "Widgets" are returned. According to the
> documentation, co=1 "allows for multiple search options to be stacked
> on top of each other". I reported some exceptions to this above, but
> now I'm thinking co=1 should be used in all searches?

Racke is right; you need co=1 if you are using "op":
http://interchange.rtfm.info/icdocs/Search_parameters.html#mv_column_op_op

--
Josh Lavin
Perusion -- Expert Interchange Consulting http://www.perusion.com/

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

emailgrant at gmail

May 22, 2012, 1:17 AM

Post #9 of 9 (225 views)
Permalink

Re: Long-lived co=1 bug [In reply to]

>> >>> I'm having a hard time pinning this down so I know when I need to use
>> >>> co=1 for a non-coordinated search. �Does anyone know when that is
>> >>> necessary?
>> >>
>> >> I think if the op= parameter is given.
>> >>
>> >> Bye
>> >> � � � �Racke
>> >
>> > About 5 1/2 years later, I think I've got this more nailed down.
>> > Adding co=1 seems to be necessary unless there is only one sf/se block
>> > and op=eq is in affect. �Is this really a bug, or am I
>> > misunderstanding mv_coordinate?
>> >
>> > This document:
>> >
>> > http://docs.icdevgroup.org/cgi-bin/online/search/search_reference.html
>> >
>> > says:
>> >
>> > "the so-called "coordinated" search allows for multiple search options
>> > to be stacked on top of each other"
>> >
>> > but it seems to be necessary even when there is only one sf/se block
>> > unless using op=eq.
>> >
>> > - Grant
>>
>> The following search returns products in the category "Widgets" and
>> products in the category "Big Widgets":
>>
>> [loop search="fi=products/st=db/sf=category/se=Widgets/op=eq/nu=0"][/loop]
>>
>> If I add co=1, only "Widgets" are returned. �According to the
>> documentation, co=1 "allows for multiple search options to be stacked
>> on top of each other". �I reported some exceptions to this above, but
>> now I'm thinking co=1 should be used in all searches?
>
> Racke is right; you need co=1 if you are using "op":
> http://interchange.rtfm.info/icdocs/Search_parameters.html#mv_column_op_op
>
> --
> Josh Lavin
> Perusion -- Expert Interchange Consulting � �http://www.perusion.com/

Got it, thank you.

- Grant

_______________________________________________
interchange-users mailing list
interchange-users [at] icdevgroup
http://www.icdevgroup.org/mailman/listinfo/interchange-users

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads