You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cayenne.apache.org by Lon Varscsak <lo...@gmail.com> on 2019/07/18 16:46:53 UTC
Re: Another regression in 4.2
Hey Nikita, this is still a problem, but looks like it's happening on
straight-forward fetches (possibly with "char" datatypes):
SELECT DISTINCT [t0].[average_cost], [t0].[backorder_flag],
[t0].[break_match_code], [t0].[case_location], [t0].[case_qty],
[t0].[category_code], [t0].[cgs_gl_account],
RTRIM([t0].[charges_group_code]), [t0].[composition_family],
[t0].[composition_output_definition], [t0].[custom_vendor],
[t0].[description], RTRIM([t0].[drop_ship_code]), [t0].[duties_percent],
[t0].[duties_tax_cost_percent], RTRIM([t0].[envelope_item_number]),
[t0].[expect_date], [t0].[first_sale_date], [t0].[freight_cost_percent],
[t0].[inventory_gl_account], [t0].[lead_time], [t0].[license_required],
RTRIM([t0].[market]), [t0].[material], [t0].[merchandise_cost_percent],
[t0].[operator_message], [t0].[origin], RTRIM([t0].[part_number]),
[t0].[personalization_flag], [t0].[primary_location],
[t0].[print_specification], [t0].[print_template],
RTRIM([t0].[procurement_code]), [t0].[qty_expected],
[t0].[qty_on_backorder], [t0].[qty_on_hand], [t0].[qty_reserved],
[t0].[qty_available], [t0].[return_gl_account], [t0].[sales_gl_account],
[t0].[sales_unit], [t0].[serial_number_flag], [t0].[special_process],
[t0].[status], [t0].[tax_flag], [t0].[tesla_qty_on_backorder],
[t0].[tesla_qty_reserved], [t0].[unit_of_measure], [t0].[vap_cost_percent],
RTRIM([t0].[vendor_code]), [t0].[weight], RTRIM([t0].[root_part_number])
FROM [production.dbo.part] [t0] WHERE *RTRIM([t0].[part_number])* = ?
[bind: 1->part_number:'120476']
On Tue, May 14, 2019 at 10:47 AM Lon Varscsak <lo...@gmail.com>
wrote:
> Thanks!
>
> On Sat, May 11, 2019 at 5:04 AM Nikita Timofeev <nt...@objectstyle.com>
> wrote:
>
>> Hi,
>>
>> Fixed this, see [1]. Thank you for another catch!
>>
>> [1] https://issues.apache.org/jira/browse/CAY-2578
>>
>> On Mon, May 6, 2019 at 11:28 PM Lon Varscsak <lo...@gmail.com>
>> wrote:
>> >
>> > Hey all,
>> >
>> > I have a join from order_detail_sales to continuity_detail based on
>> > order_number and order_line_number. When fetching the to-one
>> > getContinuityDetail I'm getting an error because the query generated is
>> > swapping the keys:
>> >
>> > SELECT [t0].[intent_date], [t0].[line_end_date], [t0].[line_setup_date],
>> > [t0].[next_ship_date], RTRIM([t0].[process_flag]), [t0].[reminder_date],
>> > [t0].[reminder_days], [t0].[scheduled_shipments], [t0].[ship_frequency],
>> > [t0].[order_number], [t0].[order_line_number] FROM
>> > [production.dbo.continuity_detail] [t0] WHERE *( ( [t0].[order_number]
>> = ?
>> > ) AND ( [t0].[order_line_number] = ? ) ) [bind: 1:1, 2:57874832]*
>> >
>> > In reality "57874832" is the order_number and "1" is the
>> order_line_number,
>> > but the query generator has swapped them. I've verified the joins in
>> the
>> > modeler (and 4.1 works).
>> >
>> > Thanks,
>> >
>> > Lon
>>
>>
>>
>> --
>> Best regards,
>> Nikita Timofeev
>>
>
Re: Another regression in 4.2
Posted by Lon Varscsak <lo...@gmail.com>.
Ah, gotcha. thx
On Wed, Jul 24, 2019 at 12:01 PM Andrus Adamchik <an...@objectstyle.org>
wrote:
> Actually we never applied RTRIM function to columns in SELECT clause (So I
> was wrong claiming that we do). Instead on the Java side we trim
> CHAR-originated Strings inside CharType. And SybaseAdapter still does that
> trimming on "master", just like it did before:
>
> // the first "true" is "trimChars"
> map.registerType(new CharType(true, false));
>
> So this part should work.
>
> Andrus
>
> > On Jul 24, 2019, at 2:18 PM, Lon Varscsak <lo...@gmail.com>
> wrote:
> >
> > Having it the SELECT side of things is probably appropriate (I'm pretty
> > sure 4.1 and before did this). Otherwise values end up being things
> > like "VALUE
> > " (padded) instead of "VALUE". It's the WHERE clause that was the
> > regression.
> >
> > On Wed, Jul 24, 2019 at 5:00 AM Arseni Bulatski <
> abulatski@objectstyle.com>
> > wrote:
> >
> >> Previous behavior in 4.1 in Sybase was not to add RTRIM in both SELECT
> and
> >> WHERE clauses.
> >> So both of them are rolled back in 4.2.
> >>
> >> On Wed, Jul 24, 2019 at 2:01 PM Andrus Adamchik <andrus@objectstyle.org
> >
> >> wrote:
> >>
> >>> Oh, I think the previous behavior was to RTRIM columns in the SELECT
> >>> clause, but not in WHERE, etc. I guess the changes to the WHERE clause
> >> is
> >>> what was rolled back?
> >>>
> >>> Andrus
> >>>
> >>>> On Jul 24, 2019, at 6:46 AM, Andrus Adamchik <an...@objectstyle.org>
> >>> wrote:
> >>>>
> >>>> I have no objections to removal of RTRIM, but I wonder if there was a
> >>> specific reason why we added it for Sybase in 4.2 though? There had to
> >> be,
> >>> right?
> >>>>
> >>>> Andrus
> >>>>
> >>>>> On Jul 24, 2019, at 4:31 AM, Arseni Bulatski <
> >> abulatski@objectstyle.com>
> >>> wrote:
> >>>>>
> >>>>> So, if the previous behavior was normal, I'll move it back.
> >>>>> This is task for it: https://issues.apache.org/jira/browse/CAY-2602
> >>>>> And this is commit for it:
> >>>>>
> >>>
> >>
> https://github.com/apache/cayenne/commit/942ba5786af9a2ed47be5a1881e390c7d7101250
> >>>>> Could you please check this change?
> >>>>> If something going wrong write to list, please.
> >>>>>
> >>>>> On Tue, Jul 23, 2019 at 8:56 PM Lon Varscsak <lon.varscsak@gmail.com
> >
> >>> wrote:
> >>>>>
> >>>>>> In 4.1.B2-SNAPSHOT, I do not get the RTRIM behavior:
> >>>>>>
> >>>>>> SELECT DISTINCT [t0].[average_cost], [t0].[backorder_flag],
> >>>>>> [t0].[break_match_code], [t0].[case_location], [t0].[case_qty],
> >>>>>> [t0].[category_code], [t0].[cgs_gl_account],
> >> [t0].[charges_group_code],
> >>>>>> [t0].[composition_family], [t0].[composition_output_definition],
> >>>>>> [t0].[custom_vendor], [t0].[description], [t0].[drop_ship_code],
> >>>>>> [t0].[duties_percent], [t0].[duties_tax_cost_percent],
> >>>>>> [t0].[envelope_item_number], [t0].[expect_date],
> >>> [t0].[first_sale_date],
> >>>>>> [t0].[freight_cost_percent], [t0].[inventory_gl_account],
> >>> [t0].[lead_time],
> >>>>>> [t0].[license_required], [t0].[market], [t0].[material],
> >>>>>> [t0].[merchandise_cost_percent], [t0].[operator_message],
> >>> [t0].[origin],
> >>>>>> [t0].[part_number], [t0].[personalization_flag],
> >>> [t0].[primary_location],
> >>>>>> [t0].[print_specification], [t0].[print_template],
> >>> [t0].[procurement_code],
> >>>>>> [t0].[qty_expected], [t0].[qty_on_backorder], [t0].[qty_on_hand],
> >>>>>> [t0].[qty_reserved], [t0].[qty_available], [t0].[return_gl_account],
> >>>>>> [t0].[sales_gl_account], [t0].[sales_unit],
> >> [t0].[serial_number_flag],
> >>>>>> [t0].[special_process], [t0].[status], [t0].[tax_flag],
> >>>>>> [t0].[tesla_qty_on_backorder], [t0].[tesla_qty_reserved],
> >>>>>> [t0].[unit_of_measure], [t0].[vap_cost_percent], [t0].[vendor_code],
> >>>>>> [t0].[weight], [t0].[root_part_number] FROM
> [production].[dbo].[part]
> >>> [t0]
> >>>>>> WHERE *[t0].[part_number] *= ? [bind: 1->part_number:'120476']
> >>>>>>
> >>>>>> Having the RTRIM on the lefthand side would cause any database to
> >>> ignore
> >>>>>> the index and do a table scan.
> >>>>>>
> >>>>>> On Tue, Jul 23, 2019 at 6:23 AM Arseni Bulatski <
> >>> abulatski@objectstyle.com
> >>>>>>>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi Lon,
> >>>>>>> I looked through your issue and tried to reproduce it.
> >>>>>>> As I understand you have table with char PK.
> >>>>>>> I run it on both 4.1 and 4.2 and have such results:
> >>>>>>> For 4.1 SELECT t0.OTHER_COL, t0.PK_COL FROM CHAR_PK_TEST t0 WHERE
> >>>>>>> RTRIM(t0.PK_COL) = ? [bind: 1->PK_COL:123]
> >>>>>>> For 4.2 SELECT RTRIM(t0.OTHER_COL), RTRIM(t0.PK_COL) FROM
> >>> CHAR_PK_TEST t0
> >>>>>>> WHERE RTRIM(t0.PK_COL) = ? [bind: 1->PK_COL:123]
> >>>>>>> Maybe you can add some more details for it?
> >>>>>>>
> >>>>>>> On Thu, Jul 18, 2019 at 7:47 PM Lon Varscsak <
> >> lon.varscsak@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Hey Nikita, this is still a problem, but looks like it's happening
> >> on
> >>>>>>>> straight-forward fetches (possibly with "char" datatypes):
> >>>>>>>>
> >>>>>>>> SELECT DISTINCT [t0].[average_cost], [t0].[backorder_flag],
> >>>>>>>> [t0].[break_match_code], [t0].[case_location], [t0].[case_qty],
> >>>>>>>> [t0].[category_code], [t0].[cgs_gl_account],
> >>>>>>>> RTRIM([t0].[charges_group_code]), [t0].[composition_family],
> >>>>>>>> [t0].[composition_output_definition], [t0].[custom_vendor],
> >>>>>>>> [t0].[description], RTRIM([t0].[drop_ship_code]),
> >>>>>> [t0].[duties_percent],
> >>>>>>>> [t0].[duties_tax_cost_percent],
> RTRIM([t0].[envelope_item_number]),
> >>>>>>>> [t0].[expect_date], [t0].[first_sale_date],
> >>>>>> [t0].[freight_cost_percent],
> >>>>>>>> [t0].[inventory_gl_account], [t0].[lead_time],
> >>> [t0].[license_required],
> >>>>>>>> RTRIM([t0].[market]), [t0].[material],
> >>> [t0].[merchandise_cost_percent],
> >>>>>>>> [t0].[operator_message], [t0].[origin], RTRIM([t0].[part_number]),
> >>>>>>>> [t0].[personalization_flag], [t0].[primary_location],
> >>>>>>>> [t0].[print_specification], [t0].[print_template],
> >>>>>>>> RTRIM([t0].[procurement_code]), [t0].[qty_expected],
> >>>>>>>> [t0].[qty_on_backorder], [t0].[qty_on_hand], [t0].[qty_reserved],
> >>>>>>>> [t0].[qty_available], [t0].[return_gl_account],
> >>>>>> [t0].[sales_gl_account],
> >>>>>>>> [t0].[sales_unit], [t0].[serial_number_flag],
> >> [t0].[special_process],
> >>>>>>>> [t0].[status], [t0].[tax_flag], [t0].[tesla_qty_on_backorder],
> >>>>>>>> [t0].[tesla_qty_reserved], [t0].[unit_of_measure],
> >>>>>>> [t0].[vap_cost_percent],
> >>>>>>>> RTRIM([t0].[vendor_code]), [t0].[weight],
> >>>>>> RTRIM([t0].[root_part_number])
> >>>>>>>> FROM [production.dbo.part] [t0] WHERE *RTRIM([t0].[part_number])*
> >> = ?
> >>>>>>>> [bind: 1->part_number:'120476']
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Tue, May 14, 2019 at 10:47 AM Lon Varscsak <
> >>> lon.varscsak@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Thanks!
> >>>>>>>>>
> >>>>>>>>> On Sat, May 11, 2019 at 5:04 AM Nikita Timofeev <
> >>>>>>>> ntimofeev@objectstyle.com>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Hi,
> >>>>>>>>>>
> >>>>>>>>>> Fixed this, see [1]. Thank you for another catch!
> >>>>>>>>>>
> >>>>>>>>>> [1] https://issues.apache.org/jira/browse/CAY-2578
> >>>>>>>>>>
> >>>>>>>>>> On Mon, May 6, 2019 at 11:28 PM Lon Varscsak <
> >>>>>> lon.varscsak@gmail.com>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Hey all,
> >>>>>>>>>>>
> >>>>>>>>>>> I have a join from order_detail_sales to continuity_detail
> based
> >>>>>> on
> >>>>>>>>>>> order_number and order_line_number. When fetching the to-one
> >>>>>>>>>>> getContinuityDetail I'm getting an error because the query
> >>>>>> generated
> >>>>>>>> is
> >>>>>>>>>>> swapping the keys:
> >>>>>>>>>>>
> >>>>>>>>>>> SELECT [t0].[intent_date], [t0].[line_end_date],
> >>>>>>>> [t0].[line_setup_date],
> >>>>>>>>>>> [t0].[next_ship_date], RTRIM([t0].[process_flag]),
> >>>>>>>> [t0].[reminder_date],
> >>>>>>>>>>> [t0].[reminder_days], [t0].[scheduled_shipments],
> >>>>>>>> [t0].[ship_frequency],
> >>>>>>>>>>> [t0].[order_number], [t0].[order_line_number] FROM
> >>>>>>>>>>> [production.dbo.continuity_detail] [t0] WHERE *( (
> >>>>>>> [t0].[order_number]
> >>>>>>>>>> = ?
> >>>>>>>>>>> ) AND ( [t0].[order_line_number] = ? ) ) [bind: 1:1,
> >> 2:57874832]*
> >>>>>>>>>>>
> >>>>>>>>>>> In reality "57874832" is the order_number and "1" is the
> >>>>>>>>>> order_line_number,
> >>>>>>>>>>> but the query generator has swapped them. I've verified the
> >> joins
> >>>>>>> in
> >>>>>>>>>> the
> >>>>>>>>>>> modeler (and 4.1 works).
> >>>>>>>>>>>
> >>>>>>>>>>> Thanks,
> >>>>>>>>>>>
> >>>>>>>>>>> Lon
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> --
> >>>>>>>>>> Best regards,
> >>>>>>>>>> Nikita Timofeev
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>
> >>>
> >>
>
>
Re: Another regression in 4.2
Posted by Andrus Adamchik <an...@objectstyle.org>.
Actually we never applied RTRIM function to columns in SELECT clause (So I was wrong claiming that we do). Instead on the Java side we trim CHAR-originated Strings inside CharType. And SybaseAdapter still does that trimming on "master", just like it did before:
// the first "true" is "trimChars"
map.registerType(new CharType(true, false));
So this part should work.
Andrus
> On Jul 24, 2019, at 2:18 PM, Lon Varscsak <lo...@gmail.com> wrote:
>
> Having it the SELECT side of things is probably appropriate (I'm pretty
> sure 4.1 and before did this). Otherwise values end up being things
> like "VALUE
> " (padded) instead of "VALUE". It's the WHERE clause that was the
> regression.
>
> On Wed, Jul 24, 2019 at 5:00 AM Arseni Bulatski <ab...@objectstyle.com>
> wrote:
>
>> Previous behavior in 4.1 in Sybase was not to add RTRIM in both SELECT and
>> WHERE clauses.
>> So both of them are rolled back in 4.2.
>>
>> On Wed, Jul 24, 2019 at 2:01 PM Andrus Adamchik <an...@objectstyle.org>
>> wrote:
>>
>>> Oh, I think the previous behavior was to RTRIM columns in the SELECT
>>> clause, but not in WHERE, etc. I guess the changes to the WHERE clause
>> is
>>> what was rolled back?
>>>
>>> Andrus
>>>
>>>> On Jul 24, 2019, at 6:46 AM, Andrus Adamchik <an...@objectstyle.org>
>>> wrote:
>>>>
>>>> I have no objections to removal of RTRIM, but I wonder if there was a
>>> specific reason why we added it for Sybase in 4.2 though? There had to
>> be,
>>> right?
>>>>
>>>> Andrus
>>>>
>>>>> On Jul 24, 2019, at 4:31 AM, Arseni Bulatski <
>> abulatski@objectstyle.com>
>>> wrote:
>>>>>
>>>>> So, if the previous behavior was normal, I'll move it back.
>>>>> This is task for it: https://issues.apache.org/jira/browse/CAY-2602
>>>>> And this is commit for it:
>>>>>
>>>
>> https://github.com/apache/cayenne/commit/942ba5786af9a2ed47be5a1881e390c7d7101250
>>>>> Could you please check this change?
>>>>> If something going wrong write to list, please.
>>>>>
>>>>> On Tue, Jul 23, 2019 at 8:56 PM Lon Varscsak <lo...@gmail.com>
>>> wrote:
>>>>>
>>>>>> In 4.1.B2-SNAPSHOT, I do not get the RTRIM behavior:
>>>>>>
>>>>>> SELECT DISTINCT [t0].[average_cost], [t0].[backorder_flag],
>>>>>> [t0].[break_match_code], [t0].[case_location], [t0].[case_qty],
>>>>>> [t0].[category_code], [t0].[cgs_gl_account],
>> [t0].[charges_group_code],
>>>>>> [t0].[composition_family], [t0].[composition_output_definition],
>>>>>> [t0].[custom_vendor], [t0].[description], [t0].[drop_ship_code],
>>>>>> [t0].[duties_percent], [t0].[duties_tax_cost_percent],
>>>>>> [t0].[envelope_item_number], [t0].[expect_date],
>>> [t0].[first_sale_date],
>>>>>> [t0].[freight_cost_percent], [t0].[inventory_gl_account],
>>> [t0].[lead_time],
>>>>>> [t0].[license_required], [t0].[market], [t0].[material],
>>>>>> [t0].[merchandise_cost_percent], [t0].[operator_message],
>>> [t0].[origin],
>>>>>> [t0].[part_number], [t0].[personalization_flag],
>>> [t0].[primary_location],
>>>>>> [t0].[print_specification], [t0].[print_template],
>>> [t0].[procurement_code],
>>>>>> [t0].[qty_expected], [t0].[qty_on_backorder], [t0].[qty_on_hand],
>>>>>> [t0].[qty_reserved], [t0].[qty_available], [t0].[return_gl_account],
>>>>>> [t0].[sales_gl_account], [t0].[sales_unit],
>> [t0].[serial_number_flag],
>>>>>> [t0].[special_process], [t0].[status], [t0].[tax_flag],
>>>>>> [t0].[tesla_qty_on_backorder], [t0].[tesla_qty_reserved],
>>>>>> [t0].[unit_of_measure], [t0].[vap_cost_percent], [t0].[vendor_code],
>>>>>> [t0].[weight], [t0].[root_part_number] FROM [production].[dbo].[part]
>>> [t0]
>>>>>> WHERE *[t0].[part_number] *= ? [bind: 1->part_number:'120476']
>>>>>>
>>>>>> Having the RTRIM on the lefthand side would cause any database to
>>> ignore
>>>>>> the index and do a table scan.
>>>>>>
>>>>>> On Tue, Jul 23, 2019 at 6:23 AM Arseni Bulatski <
>>> abulatski@objectstyle.com
>>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Lon,
>>>>>>> I looked through your issue and tried to reproduce it.
>>>>>>> As I understand you have table with char PK.
>>>>>>> I run it on both 4.1 and 4.2 and have such results:
>>>>>>> For 4.1 SELECT t0.OTHER_COL, t0.PK_COL FROM CHAR_PK_TEST t0 WHERE
>>>>>>> RTRIM(t0.PK_COL) = ? [bind: 1->PK_COL:123]
>>>>>>> For 4.2 SELECT RTRIM(t0.OTHER_COL), RTRIM(t0.PK_COL) FROM
>>> CHAR_PK_TEST t0
>>>>>>> WHERE RTRIM(t0.PK_COL) = ? [bind: 1->PK_COL:123]
>>>>>>> Maybe you can add some more details for it?
>>>>>>>
>>>>>>> On Thu, Jul 18, 2019 at 7:47 PM Lon Varscsak <
>> lon.varscsak@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hey Nikita, this is still a problem, but looks like it's happening
>> on
>>>>>>>> straight-forward fetches (possibly with "char" datatypes):
>>>>>>>>
>>>>>>>> SELECT DISTINCT [t0].[average_cost], [t0].[backorder_flag],
>>>>>>>> [t0].[break_match_code], [t0].[case_location], [t0].[case_qty],
>>>>>>>> [t0].[category_code], [t0].[cgs_gl_account],
>>>>>>>> RTRIM([t0].[charges_group_code]), [t0].[composition_family],
>>>>>>>> [t0].[composition_output_definition], [t0].[custom_vendor],
>>>>>>>> [t0].[description], RTRIM([t0].[drop_ship_code]),
>>>>>> [t0].[duties_percent],
>>>>>>>> [t0].[duties_tax_cost_percent], RTRIM([t0].[envelope_item_number]),
>>>>>>>> [t0].[expect_date], [t0].[first_sale_date],
>>>>>> [t0].[freight_cost_percent],
>>>>>>>> [t0].[inventory_gl_account], [t0].[lead_time],
>>> [t0].[license_required],
>>>>>>>> RTRIM([t0].[market]), [t0].[material],
>>> [t0].[merchandise_cost_percent],
>>>>>>>> [t0].[operator_message], [t0].[origin], RTRIM([t0].[part_number]),
>>>>>>>> [t0].[personalization_flag], [t0].[primary_location],
>>>>>>>> [t0].[print_specification], [t0].[print_template],
>>>>>>>> RTRIM([t0].[procurement_code]), [t0].[qty_expected],
>>>>>>>> [t0].[qty_on_backorder], [t0].[qty_on_hand], [t0].[qty_reserved],
>>>>>>>> [t0].[qty_available], [t0].[return_gl_account],
>>>>>> [t0].[sales_gl_account],
>>>>>>>> [t0].[sales_unit], [t0].[serial_number_flag],
>> [t0].[special_process],
>>>>>>>> [t0].[status], [t0].[tax_flag], [t0].[tesla_qty_on_backorder],
>>>>>>>> [t0].[tesla_qty_reserved], [t0].[unit_of_measure],
>>>>>>> [t0].[vap_cost_percent],
>>>>>>>> RTRIM([t0].[vendor_code]), [t0].[weight],
>>>>>> RTRIM([t0].[root_part_number])
>>>>>>>> FROM [production.dbo.part] [t0] WHERE *RTRIM([t0].[part_number])*
>> = ?
>>>>>>>> [bind: 1->part_number:'120476']
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, May 14, 2019 at 10:47 AM Lon Varscsak <
>>> lon.varscsak@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Thanks!
>>>>>>>>>
>>>>>>>>> On Sat, May 11, 2019 at 5:04 AM Nikita Timofeev <
>>>>>>>> ntimofeev@objectstyle.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> Fixed this, see [1]. Thank you for another catch!
>>>>>>>>>>
>>>>>>>>>> [1] https://issues.apache.org/jira/browse/CAY-2578
>>>>>>>>>>
>>>>>>>>>> On Mon, May 6, 2019 at 11:28 PM Lon Varscsak <
>>>>>> lon.varscsak@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hey all,
>>>>>>>>>>>
>>>>>>>>>>> I have a join from order_detail_sales to continuity_detail based
>>>>>> on
>>>>>>>>>>> order_number and order_line_number. When fetching the to-one
>>>>>>>>>>> getContinuityDetail I'm getting an error because the query
>>>>>> generated
>>>>>>>> is
>>>>>>>>>>> swapping the keys:
>>>>>>>>>>>
>>>>>>>>>>> SELECT [t0].[intent_date], [t0].[line_end_date],
>>>>>>>> [t0].[line_setup_date],
>>>>>>>>>>> [t0].[next_ship_date], RTRIM([t0].[process_flag]),
>>>>>>>> [t0].[reminder_date],
>>>>>>>>>>> [t0].[reminder_days], [t0].[scheduled_shipments],
>>>>>>>> [t0].[ship_frequency],
>>>>>>>>>>> [t0].[order_number], [t0].[order_line_number] FROM
>>>>>>>>>>> [production.dbo.continuity_detail] [t0] WHERE *( (
>>>>>>> [t0].[order_number]
>>>>>>>>>> = ?
>>>>>>>>>>> ) AND ( [t0].[order_line_number] = ? ) ) [bind: 1:1,
>> 2:57874832]*
>>>>>>>>>>>
>>>>>>>>>>> In reality "57874832" is the order_number and "1" is the
>>>>>>>>>> order_line_number,
>>>>>>>>>>> but the query generator has swapped them. I've verified the
>> joins
>>>>>>> in
>>>>>>>>>> the
>>>>>>>>>>> modeler (and 4.1 works).
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>>
>>>>>>>>>>> Lon
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Best regards,
>>>>>>>>>> Nikita Timofeev
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>>>
>>
Re: Another regression in 4.2
Posted by Lon Varscsak <lo...@gmail.com>.
Having it the SELECT side of things is probably appropriate (I'm pretty
sure 4.1 and before did this). Otherwise values end up being things
like "VALUE
" (padded) instead of "VALUE". It's the WHERE clause that was the
regression.
On Wed, Jul 24, 2019 at 5:00 AM Arseni Bulatski <ab...@objectstyle.com>
wrote:
> Previous behavior in 4.1 in Sybase was not to add RTRIM in both SELECT and
> WHERE clauses.
> So both of them are rolled back in 4.2.
>
> On Wed, Jul 24, 2019 at 2:01 PM Andrus Adamchik <an...@objectstyle.org>
> wrote:
>
> > Oh, I think the previous behavior was to RTRIM columns in the SELECT
> > clause, but not in WHERE, etc. I guess the changes to the WHERE clause
> is
> > what was rolled back?
> >
> > Andrus
> >
> > > On Jul 24, 2019, at 6:46 AM, Andrus Adamchik <an...@objectstyle.org>
> > wrote:
> > >
> > > I have no objections to removal of RTRIM, but I wonder if there was a
> > specific reason why we added it for Sybase in 4.2 though? There had to
> be,
> > right?
> > >
> > > Andrus
> > >
> > >> On Jul 24, 2019, at 4:31 AM, Arseni Bulatski <
> abulatski@objectstyle.com>
> > wrote:
> > >>
> > >> So, if the previous behavior was normal, I'll move it back.
> > >> This is task for it: https://issues.apache.org/jira/browse/CAY-2602
> > >> And this is commit for it:
> > >>
> >
> https://github.com/apache/cayenne/commit/942ba5786af9a2ed47be5a1881e390c7d7101250
> > >> Could you please check this change?
> > >> If something going wrong write to list, please.
> > >>
> > >> On Tue, Jul 23, 2019 at 8:56 PM Lon Varscsak <lo...@gmail.com>
> > wrote:
> > >>
> > >>> In 4.1.B2-SNAPSHOT, I do not get the RTRIM behavior:
> > >>>
> > >>> SELECT DISTINCT [t0].[average_cost], [t0].[backorder_flag],
> > >>> [t0].[break_match_code], [t0].[case_location], [t0].[case_qty],
> > >>> [t0].[category_code], [t0].[cgs_gl_account],
> [t0].[charges_group_code],
> > >>> [t0].[composition_family], [t0].[composition_output_definition],
> > >>> [t0].[custom_vendor], [t0].[description], [t0].[drop_ship_code],
> > >>> [t0].[duties_percent], [t0].[duties_tax_cost_percent],
> > >>> [t0].[envelope_item_number], [t0].[expect_date],
> > [t0].[first_sale_date],
> > >>> [t0].[freight_cost_percent], [t0].[inventory_gl_account],
> > [t0].[lead_time],
> > >>> [t0].[license_required], [t0].[market], [t0].[material],
> > >>> [t0].[merchandise_cost_percent], [t0].[operator_message],
> > [t0].[origin],
> > >>> [t0].[part_number], [t0].[personalization_flag],
> > [t0].[primary_location],
> > >>> [t0].[print_specification], [t0].[print_template],
> > [t0].[procurement_code],
> > >>> [t0].[qty_expected], [t0].[qty_on_backorder], [t0].[qty_on_hand],
> > >>> [t0].[qty_reserved], [t0].[qty_available], [t0].[return_gl_account],
> > >>> [t0].[sales_gl_account], [t0].[sales_unit],
> [t0].[serial_number_flag],
> > >>> [t0].[special_process], [t0].[status], [t0].[tax_flag],
> > >>> [t0].[tesla_qty_on_backorder], [t0].[tesla_qty_reserved],
> > >>> [t0].[unit_of_measure], [t0].[vap_cost_percent], [t0].[vendor_code],
> > >>> [t0].[weight], [t0].[root_part_number] FROM [production].[dbo].[part]
> > [t0]
> > >>> WHERE *[t0].[part_number] *= ? [bind: 1->part_number:'120476']
> > >>>
> > >>> Having the RTRIM on the lefthand side would cause any database to
> > ignore
> > >>> the index and do a table scan.
> > >>>
> > >>> On Tue, Jul 23, 2019 at 6:23 AM Arseni Bulatski <
> > abulatski@objectstyle.com
> > >>>>
> > >>> wrote:
> > >>>
> > >>>> Hi Lon,
> > >>>> I looked through your issue and tried to reproduce it.
> > >>>> As I understand you have table with char PK.
> > >>>> I run it on both 4.1 and 4.2 and have such results:
> > >>>> For 4.1 SELECT t0.OTHER_COL, t0.PK_COL FROM CHAR_PK_TEST t0 WHERE
> > >>>> RTRIM(t0.PK_COL) = ? [bind: 1->PK_COL:123]
> > >>>> For 4.2 SELECT RTRIM(t0.OTHER_COL), RTRIM(t0.PK_COL) FROM
> > CHAR_PK_TEST t0
> > >>>> WHERE RTRIM(t0.PK_COL) = ? [bind: 1->PK_COL:123]
> > >>>> Maybe you can add some more details for it?
> > >>>>
> > >>>> On Thu, Jul 18, 2019 at 7:47 PM Lon Varscsak <
> lon.varscsak@gmail.com>
> > >>>> wrote:
> > >>>>
> > >>>>> Hey Nikita, this is still a problem, but looks like it's happening
> on
> > >>>>> straight-forward fetches (possibly with "char" datatypes):
> > >>>>>
> > >>>>> SELECT DISTINCT [t0].[average_cost], [t0].[backorder_flag],
> > >>>>> [t0].[break_match_code], [t0].[case_location], [t0].[case_qty],
> > >>>>> [t0].[category_code], [t0].[cgs_gl_account],
> > >>>>> RTRIM([t0].[charges_group_code]), [t0].[composition_family],
> > >>>>> [t0].[composition_output_definition], [t0].[custom_vendor],
> > >>>>> [t0].[description], RTRIM([t0].[drop_ship_code]),
> > >>> [t0].[duties_percent],
> > >>>>> [t0].[duties_tax_cost_percent], RTRIM([t0].[envelope_item_number]),
> > >>>>> [t0].[expect_date], [t0].[first_sale_date],
> > >>> [t0].[freight_cost_percent],
> > >>>>> [t0].[inventory_gl_account], [t0].[lead_time],
> > [t0].[license_required],
> > >>>>> RTRIM([t0].[market]), [t0].[material],
> > [t0].[merchandise_cost_percent],
> > >>>>> [t0].[operator_message], [t0].[origin], RTRIM([t0].[part_number]),
> > >>>>> [t0].[personalization_flag], [t0].[primary_location],
> > >>>>> [t0].[print_specification], [t0].[print_template],
> > >>>>> RTRIM([t0].[procurement_code]), [t0].[qty_expected],
> > >>>>> [t0].[qty_on_backorder], [t0].[qty_on_hand], [t0].[qty_reserved],
> > >>>>> [t0].[qty_available], [t0].[return_gl_account],
> > >>> [t0].[sales_gl_account],
> > >>>>> [t0].[sales_unit], [t0].[serial_number_flag],
> [t0].[special_process],
> > >>>>> [t0].[status], [t0].[tax_flag], [t0].[tesla_qty_on_backorder],
> > >>>>> [t0].[tesla_qty_reserved], [t0].[unit_of_measure],
> > >>>> [t0].[vap_cost_percent],
> > >>>>> RTRIM([t0].[vendor_code]), [t0].[weight],
> > >>> RTRIM([t0].[root_part_number])
> > >>>>> FROM [production.dbo.part] [t0] WHERE *RTRIM([t0].[part_number])*
> = ?
> > >>>>> [bind: 1->part_number:'120476']
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>> On Tue, May 14, 2019 at 10:47 AM Lon Varscsak <
> > lon.varscsak@gmail.com>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> Thanks!
> > >>>>>>
> > >>>>>> On Sat, May 11, 2019 at 5:04 AM Nikita Timofeev <
> > >>>>> ntimofeev@objectstyle.com>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> Hi,
> > >>>>>>>
> > >>>>>>> Fixed this, see [1]. Thank you for another catch!
> > >>>>>>>
> > >>>>>>> [1] https://issues.apache.org/jira/browse/CAY-2578
> > >>>>>>>
> > >>>>>>> On Mon, May 6, 2019 at 11:28 PM Lon Varscsak <
> > >>> lon.varscsak@gmail.com>
> > >>>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>> Hey all,
> > >>>>>>>>
> > >>>>>>>> I have a join from order_detail_sales to continuity_detail based
> > >>> on
> > >>>>>>>> order_number and order_line_number. When fetching the to-one
> > >>>>>>>> getContinuityDetail I'm getting an error because the query
> > >>> generated
> > >>>>> is
> > >>>>>>>> swapping the keys:
> > >>>>>>>>
> > >>>>>>>> SELECT [t0].[intent_date], [t0].[line_end_date],
> > >>>>> [t0].[line_setup_date],
> > >>>>>>>> [t0].[next_ship_date], RTRIM([t0].[process_flag]),
> > >>>>> [t0].[reminder_date],
> > >>>>>>>> [t0].[reminder_days], [t0].[scheduled_shipments],
> > >>>>> [t0].[ship_frequency],
> > >>>>>>>> [t0].[order_number], [t0].[order_line_number] FROM
> > >>>>>>>> [production.dbo.continuity_detail] [t0] WHERE *( (
> > >>>> [t0].[order_number]
> > >>>>>>> = ?
> > >>>>>>>> ) AND ( [t0].[order_line_number] = ? ) ) [bind: 1:1,
> 2:57874832]*
> > >>>>>>>>
> > >>>>>>>> In reality "57874832" is the order_number and "1" is the
> > >>>>>>> order_line_number,
> > >>>>>>>> but the query generator has swapped them. I've verified the
> joins
> > >>>> in
> > >>>>>>> the
> > >>>>>>>> modeler (and 4.1 works).
> > >>>>>>>>
> > >>>>>>>> Thanks,
> > >>>>>>>>
> > >>>>>>>> Lon
> > >>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Best regards,
> > >>>>>>> Nikita Timofeev
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >
> >
> >
>
Re: Another regression in 4.2
Posted by Arseni Bulatski <ab...@objectstyle.com>.
Previous behavior in 4.1 in Sybase was not to add RTRIM in both SELECT and
WHERE clauses.
So both of them are rolled back in 4.2.
On Wed, Jul 24, 2019 at 2:01 PM Andrus Adamchik <an...@objectstyle.org>
wrote:
> Oh, I think the previous behavior was to RTRIM columns in the SELECT
> clause, but not in WHERE, etc. I guess the changes to the WHERE clause is
> what was rolled back?
>
> Andrus
>
> > On Jul 24, 2019, at 6:46 AM, Andrus Adamchik <an...@objectstyle.org>
> wrote:
> >
> > I have no objections to removal of RTRIM, but I wonder if there was a
> specific reason why we added it for Sybase in 4.2 though? There had to be,
> right?
> >
> > Andrus
> >
> >> On Jul 24, 2019, at 4:31 AM, Arseni Bulatski <ab...@objectstyle.com>
> wrote:
> >>
> >> So, if the previous behavior was normal, I'll move it back.
> >> This is task for it: https://issues.apache.org/jira/browse/CAY-2602
> >> And this is commit for it:
> >>
> https://github.com/apache/cayenne/commit/942ba5786af9a2ed47be5a1881e390c7d7101250
> >> Could you please check this change?
> >> If something going wrong write to list, please.
> >>
> >> On Tue, Jul 23, 2019 at 8:56 PM Lon Varscsak <lo...@gmail.com>
> wrote:
> >>
> >>> In 4.1.B2-SNAPSHOT, I do not get the RTRIM behavior:
> >>>
> >>> SELECT DISTINCT [t0].[average_cost], [t0].[backorder_flag],
> >>> [t0].[break_match_code], [t0].[case_location], [t0].[case_qty],
> >>> [t0].[category_code], [t0].[cgs_gl_account], [t0].[charges_group_code],
> >>> [t0].[composition_family], [t0].[composition_output_definition],
> >>> [t0].[custom_vendor], [t0].[description], [t0].[drop_ship_code],
> >>> [t0].[duties_percent], [t0].[duties_tax_cost_percent],
> >>> [t0].[envelope_item_number], [t0].[expect_date],
> [t0].[first_sale_date],
> >>> [t0].[freight_cost_percent], [t0].[inventory_gl_account],
> [t0].[lead_time],
> >>> [t0].[license_required], [t0].[market], [t0].[material],
> >>> [t0].[merchandise_cost_percent], [t0].[operator_message],
> [t0].[origin],
> >>> [t0].[part_number], [t0].[personalization_flag],
> [t0].[primary_location],
> >>> [t0].[print_specification], [t0].[print_template],
> [t0].[procurement_code],
> >>> [t0].[qty_expected], [t0].[qty_on_backorder], [t0].[qty_on_hand],
> >>> [t0].[qty_reserved], [t0].[qty_available], [t0].[return_gl_account],
> >>> [t0].[sales_gl_account], [t0].[sales_unit], [t0].[serial_number_flag],
> >>> [t0].[special_process], [t0].[status], [t0].[tax_flag],
> >>> [t0].[tesla_qty_on_backorder], [t0].[tesla_qty_reserved],
> >>> [t0].[unit_of_measure], [t0].[vap_cost_percent], [t0].[vendor_code],
> >>> [t0].[weight], [t0].[root_part_number] FROM [production].[dbo].[part]
> [t0]
> >>> WHERE *[t0].[part_number] *= ? [bind: 1->part_number:'120476']
> >>>
> >>> Having the RTRIM on the lefthand side would cause any database to
> ignore
> >>> the index and do a table scan.
> >>>
> >>> On Tue, Jul 23, 2019 at 6:23 AM Arseni Bulatski <
> abulatski@objectstyle.com
> >>>>
> >>> wrote:
> >>>
> >>>> Hi Lon,
> >>>> I looked through your issue and tried to reproduce it.
> >>>> As I understand you have table with char PK.
> >>>> I run it on both 4.1 and 4.2 and have such results:
> >>>> For 4.1 SELECT t0.OTHER_COL, t0.PK_COL FROM CHAR_PK_TEST t0 WHERE
> >>>> RTRIM(t0.PK_COL) = ? [bind: 1->PK_COL:123]
> >>>> For 4.2 SELECT RTRIM(t0.OTHER_COL), RTRIM(t0.PK_COL) FROM
> CHAR_PK_TEST t0
> >>>> WHERE RTRIM(t0.PK_COL) = ? [bind: 1->PK_COL:123]
> >>>> Maybe you can add some more details for it?
> >>>>
> >>>> On Thu, Jul 18, 2019 at 7:47 PM Lon Varscsak <lo...@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Hey Nikita, this is still a problem, but looks like it's happening on
> >>>>> straight-forward fetches (possibly with "char" datatypes):
> >>>>>
> >>>>> SELECT DISTINCT [t0].[average_cost], [t0].[backorder_flag],
> >>>>> [t0].[break_match_code], [t0].[case_location], [t0].[case_qty],
> >>>>> [t0].[category_code], [t0].[cgs_gl_account],
> >>>>> RTRIM([t0].[charges_group_code]), [t0].[composition_family],
> >>>>> [t0].[composition_output_definition], [t0].[custom_vendor],
> >>>>> [t0].[description], RTRIM([t0].[drop_ship_code]),
> >>> [t0].[duties_percent],
> >>>>> [t0].[duties_tax_cost_percent], RTRIM([t0].[envelope_item_number]),
> >>>>> [t0].[expect_date], [t0].[first_sale_date],
> >>> [t0].[freight_cost_percent],
> >>>>> [t0].[inventory_gl_account], [t0].[lead_time],
> [t0].[license_required],
> >>>>> RTRIM([t0].[market]), [t0].[material],
> [t0].[merchandise_cost_percent],
> >>>>> [t0].[operator_message], [t0].[origin], RTRIM([t0].[part_number]),
> >>>>> [t0].[personalization_flag], [t0].[primary_location],
> >>>>> [t0].[print_specification], [t0].[print_template],
> >>>>> RTRIM([t0].[procurement_code]), [t0].[qty_expected],
> >>>>> [t0].[qty_on_backorder], [t0].[qty_on_hand], [t0].[qty_reserved],
> >>>>> [t0].[qty_available], [t0].[return_gl_account],
> >>> [t0].[sales_gl_account],
> >>>>> [t0].[sales_unit], [t0].[serial_number_flag], [t0].[special_process],
> >>>>> [t0].[status], [t0].[tax_flag], [t0].[tesla_qty_on_backorder],
> >>>>> [t0].[tesla_qty_reserved], [t0].[unit_of_measure],
> >>>> [t0].[vap_cost_percent],
> >>>>> RTRIM([t0].[vendor_code]), [t0].[weight],
> >>> RTRIM([t0].[root_part_number])
> >>>>> FROM [production.dbo.part] [t0] WHERE *RTRIM([t0].[part_number])* = ?
> >>>>> [bind: 1->part_number:'120476']
> >>>>>
> >>>>>
> >>>>>
> >>>>> On Tue, May 14, 2019 at 10:47 AM Lon Varscsak <
> lon.varscsak@gmail.com>
> >>>>> wrote:
> >>>>>
> >>>>>> Thanks!
> >>>>>>
> >>>>>> On Sat, May 11, 2019 at 5:04 AM Nikita Timofeev <
> >>>>> ntimofeev@objectstyle.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hi,
> >>>>>>>
> >>>>>>> Fixed this, see [1]. Thank you for another catch!
> >>>>>>>
> >>>>>>> [1] https://issues.apache.org/jira/browse/CAY-2578
> >>>>>>>
> >>>>>>> On Mon, May 6, 2019 at 11:28 PM Lon Varscsak <
> >>> lon.varscsak@gmail.com>
> >>>>>>> wrote:
> >>>>>>>>
> >>>>>>>> Hey all,
> >>>>>>>>
> >>>>>>>> I have a join from order_detail_sales to continuity_detail based
> >>> on
> >>>>>>>> order_number and order_line_number. When fetching the to-one
> >>>>>>>> getContinuityDetail I'm getting an error because the query
> >>> generated
> >>>>> is
> >>>>>>>> swapping the keys:
> >>>>>>>>
> >>>>>>>> SELECT [t0].[intent_date], [t0].[line_end_date],
> >>>>> [t0].[line_setup_date],
> >>>>>>>> [t0].[next_ship_date], RTRIM([t0].[process_flag]),
> >>>>> [t0].[reminder_date],
> >>>>>>>> [t0].[reminder_days], [t0].[scheduled_shipments],
> >>>>> [t0].[ship_frequency],
> >>>>>>>> [t0].[order_number], [t0].[order_line_number] FROM
> >>>>>>>> [production.dbo.continuity_detail] [t0] WHERE *( (
> >>>> [t0].[order_number]
> >>>>>>> = ?
> >>>>>>>> ) AND ( [t0].[order_line_number] = ? ) ) [bind: 1:1, 2:57874832]*
> >>>>>>>>
> >>>>>>>> In reality "57874832" is the order_number and "1" is the
> >>>>>>> order_line_number,
> >>>>>>>> but the query generator has swapped them. I've verified the joins
> >>>> in
> >>>>>>> the
> >>>>>>>> modeler (and 4.1 works).
> >>>>>>>>
> >>>>>>>> Thanks,
> >>>>>>>>
> >>>>>>>> Lon
> >>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Best regards,
> >>>>>>> Nikita Timofeev
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>
> >
>
>
Re: Another regression in 4.2
Posted by Andrus Adamchik <an...@objectstyle.org>.
Oh, I think the previous behavior was to RTRIM columns in the SELECT clause, but not in WHERE, etc. I guess the changes to the WHERE clause is what was rolled back?
Andrus
> On Jul 24, 2019, at 6:46 AM, Andrus Adamchik <an...@objectstyle.org> wrote:
>
> I have no objections to removal of RTRIM, but I wonder if there was a specific reason why we added it for Sybase in 4.2 though? There had to be, right?
>
> Andrus
>
>> On Jul 24, 2019, at 4:31 AM, Arseni Bulatski <ab...@objectstyle.com> wrote:
>>
>> So, if the previous behavior was normal, I'll move it back.
>> This is task for it: https://issues.apache.org/jira/browse/CAY-2602
>> And this is commit for it:
>> https://github.com/apache/cayenne/commit/942ba5786af9a2ed47be5a1881e390c7d7101250
>> Could you please check this change?
>> If something going wrong write to list, please.
>>
>> On Tue, Jul 23, 2019 at 8:56 PM Lon Varscsak <lo...@gmail.com> wrote:
>>
>>> In 4.1.B2-SNAPSHOT, I do not get the RTRIM behavior:
>>>
>>> SELECT DISTINCT [t0].[average_cost], [t0].[backorder_flag],
>>> [t0].[break_match_code], [t0].[case_location], [t0].[case_qty],
>>> [t0].[category_code], [t0].[cgs_gl_account], [t0].[charges_group_code],
>>> [t0].[composition_family], [t0].[composition_output_definition],
>>> [t0].[custom_vendor], [t0].[description], [t0].[drop_ship_code],
>>> [t0].[duties_percent], [t0].[duties_tax_cost_percent],
>>> [t0].[envelope_item_number], [t0].[expect_date], [t0].[first_sale_date],
>>> [t0].[freight_cost_percent], [t0].[inventory_gl_account], [t0].[lead_time],
>>> [t0].[license_required], [t0].[market], [t0].[material],
>>> [t0].[merchandise_cost_percent], [t0].[operator_message], [t0].[origin],
>>> [t0].[part_number], [t0].[personalization_flag], [t0].[primary_location],
>>> [t0].[print_specification], [t0].[print_template], [t0].[procurement_code],
>>> [t0].[qty_expected], [t0].[qty_on_backorder], [t0].[qty_on_hand],
>>> [t0].[qty_reserved], [t0].[qty_available], [t0].[return_gl_account],
>>> [t0].[sales_gl_account], [t0].[sales_unit], [t0].[serial_number_flag],
>>> [t0].[special_process], [t0].[status], [t0].[tax_flag],
>>> [t0].[tesla_qty_on_backorder], [t0].[tesla_qty_reserved],
>>> [t0].[unit_of_measure], [t0].[vap_cost_percent], [t0].[vendor_code],
>>> [t0].[weight], [t0].[root_part_number] FROM [production].[dbo].[part] [t0]
>>> WHERE *[t0].[part_number] *= ? [bind: 1->part_number:'120476']
>>>
>>> Having the RTRIM on the lefthand side would cause any database to ignore
>>> the index and do a table scan.
>>>
>>> On Tue, Jul 23, 2019 at 6:23 AM Arseni Bulatski <abulatski@objectstyle.com
>>>>
>>> wrote:
>>>
>>>> Hi Lon,
>>>> I looked through your issue and tried to reproduce it.
>>>> As I understand you have table with char PK.
>>>> I run it on both 4.1 and 4.2 and have such results:
>>>> For 4.1 SELECT t0.OTHER_COL, t0.PK_COL FROM CHAR_PK_TEST t0 WHERE
>>>> RTRIM(t0.PK_COL) = ? [bind: 1->PK_COL:123]
>>>> For 4.2 SELECT RTRIM(t0.OTHER_COL), RTRIM(t0.PK_COL) FROM CHAR_PK_TEST t0
>>>> WHERE RTRIM(t0.PK_COL) = ? [bind: 1->PK_COL:123]
>>>> Maybe you can add some more details for it?
>>>>
>>>> On Thu, Jul 18, 2019 at 7:47 PM Lon Varscsak <lo...@gmail.com>
>>>> wrote:
>>>>
>>>>> Hey Nikita, this is still a problem, but looks like it's happening on
>>>>> straight-forward fetches (possibly with "char" datatypes):
>>>>>
>>>>> SELECT DISTINCT [t0].[average_cost], [t0].[backorder_flag],
>>>>> [t0].[break_match_code], [t0].[case_location], [t0].[case_qty],
>>>>> [t0].[category_code], [t0].[cgs_gl_account],
>>>>> RTRIM([t0].[charges_group_code]), [t0].[composition_family],
>>>>> [t0].[composition_output_definition], [t0].[custom_vendor],
>>>>> [t0].[description], RTRIM([t0].[drop_ship_code]),
>>> [t0].[duties_percent],
>>>>> [t0].[duties_tax_cost_percent], RTRIM([t0].[envelope_item_number]),
>>>>> [t0].[expect_date], [t0].[first_sale_date],
>>> [t0].[freight_cost_percent],
>>>>> [t0].[inventory_gl_account], [t0].[lead_time], [t0].[license_required],
>>>>> RTRIM([t0].[market]), [t0].[material], [t0].[merchandise_cost_percent],
>>>>> [t0].[operator_message], [t0].[origin], RTRIM([t0].[part_number]),
>>>>> [t0].[personalization_flag], [t0].[primary_location],
>>>>> [t0].[print_specification], [t0].[print_template],
>>>>> RTRIM([t0].[procurement_code]), [t0].[qty_expected],
>>>>> [t0].[qty_on_backorder], [t0].[qty_on_hand], [t0].[qty_reserved],
>>>>> [t0].[qty_available], [t0].[return_gl_account],
>>> [t0].[sales_gl_account],
>>>>> [t0].[sales_unit], [t0].[serial_number_flag], [t0].[special_process],
>>>>> [t0].[status], [t0].[tax_flag], [t0].[tesla_qty_on_backorder],
>>>>> [t0].[tesla_qty_reserved], [t0].[unit_of_measure],
>>>> [t0].[vap_cost_percent],
>>>>> RTRIM([t0].[vendor_code]), [t0].[weight],
>>> RTRIM([t0].[root_part_number])
>>>>> FROM [production.dbo.part] [t0] WHERE *RTRIM([t0].[part_number])* = ?
>>>>> [bind: 1->part_number:'120476']
>>>>>
>>>>>
>>>>>
>>>>> On Tue, May 14, 2019 at 10:47 AM Lon Varscsak <lo...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Thanks!
>>>>>>
>>>>>> On Sat, May 11, 2019 at 5:04 AM Nikita Timofeev <
>>>>> ntimofeev@objectstyle.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi,
>>>>>>>
>>>>>>> Fixed this, see [1]. Thank you for another catch!
>>>>>>>
>>>>>>> [1] https://issues.apache.org/jira/browse/CAY-2578
>>>>>>>
>>>>>>> On Mon, May 6, 2019 at 11:28 PM Lon Varscsak <
>>> lon.varscsak@gmail.com>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Hey all,
>>>>>>>>
>>>>>>>> I have a join from order_detail_sales to continuity_detail based
>>> on
>>>>>>>> order_number and order_line_number. When fetching the to-one
>>>>>>>> getContinuityDetail I'm getting an error because the query
>>> generated
>>>>> is
>>>>>>>> swapping the keys:
>>>>>>>>
>>>>>>>> SELECT [t0].[intent_date], [t0].[line_end_date],
>>>>> [t0].[line_setup_date],
>>>>>>>> [t0].[next_ship_date], RTRIM([t0].[process_flag]),
>>>>> [t0].[reminder_date],
>>>>>>>> [t0].[reminder_days], [t0].[scheduled_shipments],
>>>>> [t0].[ship_frequency],
>>>>>>>> [t0].[order_number], [t0].[order_line_number] FROM
>>>>>>>> [production.dbo.continuity_detail] [t0] WHERE *( (
>>>> [t0].[order_number]
>>>>>>> = ?
>>>>>>>> ) AND ( [t0].[order_line_number] = ? ) ) [bind: 1:1, 2:57874832]*
>>>>>>>>
>>>>>>>> In reality "57874832" is the order_number and "1" is the
>>>>>>> order_line_number,
>>>>>>>> but the query generator has swapped them. I've verified the joins
>>>> in
>>>>>>> the
>>>>>>>> modeler (and 4.1 works).
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>>
>>>>>>>> Lon
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Best regards,
>>>>>>> Nikita Timofeev
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>
Re: Another regression in 4.2
Posted by Andrus Adamchik <an...@objectstyle.org>.
I have no objections to removal of RTRIM, but I wonder if there was a specific reason why we added it for Sybase in 4.2 though? There had to be, right?
Andrus
> On Jul 24, 2019, at 4:31 AM, Arseni Bulatski <ab...@objectstyle.com> wrote:
>
> So, if the previous behavior was normal, I'll move it back.
> This is task for it: https://issues.apache.org/jira/browse/CAY-2602
> And this is commit for it:
> https://github.com/apache/cayenne/commit/942ba5786af9a2ed47be5a1881e390c7d7101250
> Could you please check this change?
> If something going wrong write to list, please.
>
> On Tue, Jul 23, 2019 at 8:56 PM Lon Varscsak <lo...@gmail.com> wrote:
>
>> In 4.1.B2-SNAPSHOT, I do not get the RTRIM behavior:
>>
>> SELECT DISTINCT [t0].[average_cost], [t0].[backorder_flag],
>> [t0].[break_match_code], [t0].[case_location], [t0].[case_qty],
>> [t0].[category_code], [t0].[cgs_gl_account], [t0].[charges_group_code],
>> [t0].[composition_family], [t0].[composition_output_definition],
>> [t0].[custom_vendor], [t0].[description], [t0].[drop_ship_code],
>> [t0].[duties_percent], [t0].[duties_tax_cost_percent],
>> [t0].[envelope_item_number], [t0].[expect_date], [t0].[first_sale_date],
>> [t0].[freight_cost_percent], [t0].[inventory_gl_account], [t0].[lead_time],
>> [t0].[license_required], [t0].[market], [t0].[material],
>> [t0].[merchandise_cost_percent], [t0].[operator_message], [t0].[origin],
>> [t0].[part_number], [t0].[personalization_flag], [t0].[primary_location],
>> [t0].[print_specification], [t0].[print_template], [t0].[procurement_code],
>> [t0].[qty_expected], [t0].[qty_on_backorder], [t0].[qty_on_hand],
>> [t0].[qty_reserved], [t0].[qty_available], [t0].[return_gl_account],
>> [t0].[sales_gl_account], [t0].[sales_unit], [t0].[serial_number_flag],
>> [t0].[special_process], [t0].[status], [t0].[tax_flag],
>> [t0].[tesla_qty_on_backorder], [t0].[tesla_qty_reserved],
>> [t0].[unit_of_measure], [t0].[vap_cost_percent], [t0].[vendor_code],
>> [t0].[weight], [t0].[root_part_number] FROM [production].[dbo].[part] [t0]
>> WHERE *[t0].[part_number] *= ? [bind: 1->part_number:'120476']
>>
>> Having the RTRIM on the lefthand side would cause any database to ignore
>> the index and do a table scan.
>>
>> On Tue, Jul 23, 2019 at 6:23 AM Arseni Bulatski <abulatski@objectstyle.com
>>>
>> wrote:
>>
>>> Hi Lon,
>>> I looked through your issue and tried to reproduce it.
>>> As I understand you have table with char PK.
>>> I run it on both 4.1 and 4.2 and have such results:
>>> For 4.1 SELECT t0.OTHER_COL, t0.PK_COL FROM CHAR_PK_TEST t0 WHERE
>>> RTRIM(t0.PK_COL) = ? [bind: 1->PK_COL:123]
>>> For 4.2 SELECT RTRIM(t0.OTHER_COL), RTRIM(t0.PK_COL) FROM CHAR_PK_TEST t0
>>> WHERE RTRIM(t0.PK_COL) = ? [bind: 1->PK_COL:123]
>>> Maybe you can add some more details for it?
>>>
>>> On Thu, Jul 18, 2019 at 7:47 PM Lon Varscsak <lo...@gmail.com>
>>> wrote:
>>>
>>>> Hey Nikita, this is still a problem, but looks like it's happening on
>>>> straight-forward fetches (possibly with "char" datatypes):
>>>>
>>>> SELECT DISTINCT [t0].[average_cost], [t0].[backorder_flag],
>>>> [t0].[break_match_code], [t0].[case_location], [t0].[case_qty],
>>>> [t0].[category_code], [t0].[cgs_gl_account],
>>>> RTRIM([t0].[charges_group_code]), [t0].[composition_family],
>>>> [t0].[composition_output_definition], [t0].[custom_vendor],
>>>> [t0].[description], RTRIM([t0].[drop_ship_code]),
>> [t0].[duties_percent],
>>>> [t0].[duties_tax_cost_percent], RTRIM([t0].[envelope_item_number]),
>>>> [t0].[expect_date], [t0].[first_sale_date],
>> [t0].[freight_cost_percent],
>>>> [t0].[inventory_gl_account], [t0].[lead_time], [t0].[license_required],
>>>> RTRIM([t0].[market]), [t0].[material], [t0].[merchandise_cost_percent],
>>>> [t0].[operator_message], [t0].[origin], RTRIM([t0].[part_number]),
>>>> [t0].[personalization_flag], [t0].[primary_location],
>>>> [t0].[print_specification], [t0].[print_template],
>>>> RTRIM([t0].[procurement_code]), [t0].[qty_expected],
>>>> [t0].[qty_on_backorder], [t0].[qty_on_hand], [t0].[qty_reserved],
>>>> [t0].[qty_available], [t0].[return_gl_account],
>> [t0].[sales_gl_account],
>>>> [t0].[sales_unit], [t0].[serial_number_flag], [t0].[special_process],
>>>> [t0].[status], [t0].[tax_flag], [t0].[tesla_qty_on_backorder],
>>>> [t0].[tesla_qty_reserved], [t0].[unit_of_measure],
>>> [t0].[vap_cost_percent],
>>>> RTRIM([t0].[vendor_code]), [t0].[weight],
>> RTRIM([t0].[root_part_number])
>>>> FROM [production.dbo.part] [t0] WHERE *RTRIM([t0].[part_number])* = ?
>>>> [bind: 1->part_number:'120476']
>>>>
>>>>
>>>>
>>>> On Tue, May 14, 2019 at 10:47 AM Lon Varscsak <lo...@gmail.com>
>>>> wrote:
>>>>
>>>>> Thanks!
>>>>>
>>>>> On Sat, May 11, 2019 at 5:04 AM Nikita Timofeev <
>>>> ntimofeev@objectstyle.com>
>>>>> wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Fixed this, see [1]. Thank you for another catch!
>>>>>>
>>>>>> [1] https://issues.apache.org/jira/browse/CAY-2578
>>>>>>
>>>>>> On Mon, May 6, 2019 at 11:28 PM Lon Varscsak <
>> lon.varscsak@gmail.com>
>>>>>> wrote:
>>>>>>>
>>>>>>> Hey all,
>>>>>>>
>>>>>>> I have a join from order_detail_sales to continuity_detail based
>> on
>>>>>>> order_number and order_line_number. When fetching the to-one
>>>>>>> getContinuityDetail I'm getting an error because the query
>> generated
>>>> is
>>>>>>> swapping the keys:
>>>>>>>
>>>>>>> SELECT [t0].[intent_date], [t0].[line_end_date],
>>>> [t0].[line_setup_date],
>>>>>>> [t0].[next_ship_date], RTRIM([t0].[process_flag]),
>>>> [t0].[reminder_date],
>>>>>>> [t0].[reminder_days], [t0].[scheduled_shipments],
>>>> [t0].[ship_frequency],
>>>>>>> [t0].[order_number], [t0].[order_line_number] FROM
>>>>>>> [production.dbo.continuity_detail] [t0] WHERE *( (
>>> [t0].[order_number]
>>>>>> = ?
>>>>>>> ) AND ( [t0].[order_line_number] = ? ) ) [bind: 1:1, 2:57874832]*
>>>>>>>
>>>>>>> In reality "57874832" is the order_number and "1" is the
>>>>>> order_line_number,
>>>>>>> but the query generator has swapped them. I've verified the joins
>>> in
>>>>>> the
>>>>>>> modeler (and 4.1 works).
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> Lon
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Best regards,
>>>>>> Nikita Timofeev
>>>>>>
>>>>>
>>>>
>>>
>>
Re: Another regression in 4.2
Posted by Arseni Bulatski <ab...@objectstyle.com>.
So, if the previous behavior was normal, I'll move it back.
This is task for it: https://issues.apache.org/jira/browse/CAY-2602
And this is commit for it:
https://github.com/apache/cayenne/commit/942ba5786af9a2ed47be5a1881e390c7d7101250
Could you please check this change?
If something going wrong write to list, please.
On Tue, Jul 23, 2019 at 8:56 PM Lon Varscsak <lo...@gmail.com> wrote:
> In 4.1.B2-SNAPSHOT, I do not get the RTRIM behavior:
>
> SELECT DISTINCT [t0].[average_cost], [t0].[backorder_flag],
> [t0].[break_match_code], [t0].[case_location], [t0].[case_qty],
> [t0].[category_code], [t0].[cgs_gl_account], [t0].[charges_group_code],
> [t0].[composition_family], [t0].[composition_output_definition],
> [t0].[custom_vendor], [t0].[description], [t0].[drop_ship_code],
> [t0].[duties_percent], [t0].[duties_tax_cost_percent],
> [t0].[envelope_item_number], [t0].[expect_date], [t0].[first_sale_date],
> [t0].[freight_cost_percent], [t0].[inventory_gl_account], [t0].[lead_time],
> [t0].[license_required], [t0].[market], [t0].[material],
> [t0].[merchandise_cost_percent], [t0].[operator_message], [t0].[origin],
> [t0].[part_number], [t0].[personalization_flag], [t0].[primary_location],
> [t0].[print_specification], [t0].[print_template], [t0].[procurement_code],
> [t0].[qty_expected], [t0].[qty_on_backorder], [t0].[qty_on_hand],
> [t0].[qty_reserved], [t0].[qty_available], [t0].[return_gl_account],
> [t0].[sales_gl_account], [t0].[sales_unit], [t0].[serial_number_flag],
> [t0].[special_process], [t0].[status], [t0].[tax_flag],
> [t0].[tesla_qty_on_backorder], [t0].[tesla_qty_reserved],
> [t0].[unit_of_measure], [t0].[vap_cost_percent], [t0].[vendor_code],
> [t0].[weight], [t0].[root_part_number] FROM [production].[dbo].[part] [t0]
> WHERE *[t0].[part_number] *= ? [bind: 1->part_number:'120476']
>
> Having the RTRIM on the lefthand side would cause any database to ignore
> the index and do a table scan.
>
> On Tue, Jul 23, 2019 at 6:23 AM Arseni Bulatski <abulatski@objectstyle.com
> >
> wrote:
>
> > Hi Lon,
> > I looked through your issue and tried to reproduce it.
> > As I understand you have table with char PK.
> > I run it on both 4.1 and 4.2 and have such results:
> > For 4.1 SELECT t0.OTHER_COL, t0.PK_COL FROM CHAR_PK_TEST t0 WHERE
> > RTRIM(t0.PK_COL) = ? [bind: 1->PK_COL:123]
> > For 4.2 SELECT RTRIM(t0.OTHER_COL), RTRIM(t0.PK_COL) FROM CHAR_PK_TEST t0
> > WHERE RTRIM(t0.PK_COL) = ? [bind: 1->PK_COL:123]
> > Maybe you can add some more details for it?
> >
> > On Thu, Jul 18, 2019 at 7:47 PM Lon Varscsak <lo...@gmail.com>
> > wrote:
> >
> > > Hey Nikita, this is still a problem, but looks like it's happening on
> > > straight-forward fetches (possibly with "char" datatypes):
> > >
> > > SELECT DISTINCT [t0].[average_cost], [t0].[backorder_flag],
> > > [t0].[break_match_code], [t0].[case_location], [t0].[case_qty],
> > > [t0].[category_code], [t0].[cgs_gl_account],
> > > RTRIM([t0].[charges_group_code]), [t0].[composition_family],
> > > [t0].[composition_output_definition], [t0].[custom_vendor],
> > > [t0].[description], RTRIM([t0].[drop_ship_code]),
> [t0].[duties_percent],
> > > [t0].[duties_tax_cost_percent], RTRIM([t0].[envelope_item_number]),
> > > [t0].[expect_date], [t0].[first_sale_date],
> [t0].[freight_cost_percent],
> > > [t0].[inventory_gl_account], [t0].[lead_time], [t0].[license_required],
> > > RTRIM([t0].[market]), [t0].[material], [t0].[merchandise_cost_percent],
> > > [t0].[operator_message], [t0].[origin], RTRIM([t0].[part_number]),
> > > [t0].[personalization_flag], [t0].[primary_location],
> > > [t0].[print_specification], [t0].[print_template],
> > > RTRIM([t0].[procurement_code]), [t0].[qty_expected],
> > > [t0].[qty_on_backorder], [t0].[qty_on_hand], [t0].[qty_reserved],
> > > [t0].[qty_available], [t0].[return_gl_account],
> [t0].[sales_gl_account],
> > > [t0].[sales_unit], [t0].[serial_number_flag], [t0].[special_process],
> > > [t0].[status], [t0].[tax_flag], [t0].[tesla_qty_on_backorder],
> > > [t0].[tesla_qty_reserved], [t0].[unit_of_measure],
> > [t0].[vap_cost_percent],
> > > RTRIM([t0].[vendor_code]), [t0].[weight],
> RTRIM([t0].[root_part_number])
> > > FROM [production.dbo.part] [t0] WHERE *RTRIM([t0].[part_number])* = ?
> > > [bind: 1->part_number:'120476']
> > >
> > >
> > >
> > > On Tue, May 14, 2019 at 10:47 AM Lon Varscsak <lo...@gmail.com>
> > > wrote:
> > >
> > > > Thanks!
> > > >
> > > > On Sat, May 11, 2019 at 5:04 AM Nikita Timofeev <
> > > ntimofeev@objectstyle.com>
> > > > wrote:
> > > >
> > > >> Hi,
> > > >>
> > > >> Fixed this, see [1]. Thank you for another catch!
> > > >>
> > > >> [1] https://issues.apache.org/jira/browse/CAY-2578
> > > >>
> > > >> On Mon, May 6, 2019 at 11:28 PM Lon Varscsak <
> lon.varscsak@gmail.com>
> > > >> wrote:
> > > >> >
> > > >> > Hey all,
> > > >> >
> > > >> > I have a join from order_detail_sales to continuity_detail based
> on
> > > >> > order_number and order_line_number. When fetching the to-one
> > > >> > getContinuityDetail I'm getting an error because the query
> generated
> > > is
> > > >> > swapping the keys:
> > > >> >
> > > >> > SELECT [t0].[intent_date], [t0].[line_end_date],
> > > [t0].[line_setup_date],
> > > >> > [t0].[next_ship_date], RTRIM([t0].[process_flag]),
> > > [t0].[reminder_date],
> > > >> > [t0].[reminder_days], [t0].[scheduled_shipments],
> > > [t0].[ship_frequency],
> > > >> > [t0].[order_number], [t0].[order_line_number] FROM
> > > >> > [production.dbo.continuity_detail] [t0] WHERE *( (
> > [t0].[order_number]
> > > >> = ?
> > > >> > ) AND ( [t0].[order_line_number] = ? ) ) [bind: 1:1, 2:57874832]*
> > > >> >
> > > >> > In reality "57874832" is the order_number and "1" is the
> > > >> order_line_number,
> > > >> > but the query generator has swapped them. I've verified the joins
> > in
> > > >> the
> > > >> > modeler (and 4.1 works).
> > > >> >
> > > >> > Thanks,
> > > >> >
> > > >> > Lon
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Best regards,
> > > >> Nikita Timofeev
> > > >>
> > > >
> > >
> >
>
Re: Another regression in 4.2
Posted by Lon Varscsak <lo...@gmail.com>.
In 4.1.B2-SNAPSHOT, I do not get the RTRIM behavior:
SELECT DISTINCT [t0].[average_cost], [t0].[backorder_flag],
[t0].[break_match_code], [t0].[case_location], [t0].[case_qty],
[t0].[category_code], [t0].[cgs_gl_account], [t0].[charges_group_code],
[t0].[composition_family], [t0].[composition_output_definition],
[t0].[custom_vendor], [t0].[description], [t0].[drop_ship_code],
[t0].[duties_percent], [t0].[duties_tax_cost_percent],
[t0].[envelope_item_number], [t0].[expect_date], [t0].[first_sale_date],
[t0].[freight_cost_percent], [t0].[inventory_gl_account], [t0].[lead_time],
[t0].[license_required], [t0].[market], [t0].[material],
[t0].[merchandise_cost_percent], [t0].[operator_message], [t0].[origin],
[t0].[part_number], [t0].[personalization_flag], [t0].[primary_location],
[t0].[print_specification], [t0].[print_template], [t0].[procurement_code],
[t0].[qty_expected], [t0].[qty_on_backorder], [t0].[qty_on_hand],
[t0].[qty_reserved], [t0].[qty_available], [t0].[return_gl_account],
[t0].[sales_gl_account], [t0].[sales_unit], [t0].[serial_number_flag],
[t0].[special_process], [t0].[status], [t0].[tax_flag],
[t0].[tesla_qty_on_backorder], [t0].[tesla_qty_reserved],
[t0].[unit_of_measure], [t0].[vap_cost_percent], [t0].[vendor_code],
[t0].[weight], [t0].[root_part_number] FROM [production].[dbo].[part] [t0]
WHERE *[t0].[part_number] *= ? [bind: 1->part_number:'120476']
Having the RTRIM on the lefthand side would cause any database to ignore
the index and do a table scan.
On Tue, Jul 23, 2019 at 6:23 AM Arseni Bulatski <ab...@objectstyle.com>
wrote:
> Hi Lon,
> I looked through your issue and tried to reproduce it.
> As I understand you have table with char PK.
> I run it on both 4.1 and 4.2 and have such results:
> For 4.1 SELECT t0.OTHER_COL, t0.PK_COL FROM CHAR_PK_TEST t0 WHERE
> RTRIM(t0.PK_COL) = ? [bind: 1->PK_COL:123]
> For 4.2 SELECT RTRIM(t0.OTHER_COL), RTRIM(t0.PK_COL) FROM CHAR_PK_TEST t0
> WHERE RTRIM(t0.PK_COL) = ? [bind: 1->PK_COL:123]
> Maybe you can add some more details for it?
>
> On Thu, Jul 18, 2019 at 7:47 PM Lon Varscsak <lo...@gmail.com>
> wrote:
>
> > Hey Nikita, this is still a problem, but looks like it's happening on
> > straight-forward fetches (possibly with "char" datatypes):
> >
> > SELECT DISTINCT [t0].[average_cost], [t0].[backorder_flag],
> > [t0].[break_match_code], [t0].[case_location], [t0].[case_qty],
> > [t0].[category_code], [t0].[cgs_gl_account],
> > RTRIM([t0].[charges_group_code]), [t0].[composition_family],
> > [t0].[composition_output_definition], [t0].[custom_vendor],
> > [t0].[description], RTRIM([t0].[drop_ship_code]), [t0].[duties_percent],
> > [t0].[duties_tax_cost_percent], RTRIM([t0].[envelope_item_number]),
> > [t0].[expect_date], [t0].[first_sale_date], [t0].[freight_cost_percent],
> > [t0].[inventory_gl_account], [t0].[lead_time], [t0].[license_required],
> > RTRIM([t0].[market]), [t0].[material], [t0].[merchandise_cost_percent],
> > [t0].[operator_message], [t0].[origin], RTRIM([t0].[part_number]),
> > [t0].[personalization_flag], [t0].[primary_location],
> > [t0].[print_specification], [t0].[print_template],
> > RTRIM([t0].[procurement_code]), [t0].[qty_expected],
> > [t0].[qty_on_backorder], [t0].[qty_on_hand], [t0].[qty_reserved],
> > [t0].[qty_available], [t0].[return_gl_account], [t0].[sales_gl_account],
> > [t0].[sales_unit], [t0].[serial_number_flag], [t0].[special_process],
> > [t0].[status], [t0].[tax_flag], [t0].[tesla_qty_on_backorder],
> > [t0].[tesla_qty_reserved], [t0].[unit_of_measure],
> [t0].[vap_cost_percent],
> > RTRIM([t0].[vendor_code]), [t0].[weight], RTRIM([t0].[root_part_number])
> > FROM [production.dbo.part] [t0] WHERE *RTRIM([t0].[part_number])* = ?
> > [bind: 1->part_number:'120476']
> >
> >
> >
> > On Tue, May 14, 2019 at 10:47 AM Lon Varscsak <lo...@gmail.com>
> > wrote:
> >
> > > Thanks!
> > >
> > > On Sat, May 11, 2019 at 5:04 AM Nikita Timofeev <
> > ntimofeev@objectstyle.com>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> Fixed this, see [1]. Thank you for another catch!
> > >>
> > >> [1] https://issues.apache.org/jira/browse/CAY-2578
> > >>
> > >> On Mon, May 6, 2019 at 11:28 PM Lon Varscsak <lo...@gmail.com>
> > >> wrote:
> > >> >
> > >> > Hey all,
> > >> >
> > >> > I have a join from order_detail_sales to continuity_detail based on
> > >> > order_number and order_line_number. When fetching the to-one
> > >> > getContinuityDetail I'm getting an error because the query generated
> > is
> > >> > swapping the keys:
> > >> >
> > >> > SELECT [t0].[intent_date], [t0].[line_end_date],
> > [t0].[line_setup_date],
> > >> > [t0].[next_ship_date], RTRIM([t0].[process_flag]),
> > [t0].[reminder_date],
> > >> > [t0].[reminder_days], [t0].[scheduled_shipments],
> > [t0].[ship_frequency],
> > >> > [t0].[order_number], [t0].[order_line_number] FROM
> > >> > [production.dbo.continuity_detail] [t0] WHERE *( (
> [t0].[order_number]
> > >> = ?
> > >> > ) AND ( [t0].[order_line_number] = ? ) ) [bind: 1:1, 2:57874832]*
> > >> >
> > >> > In reality "57874832" is the order_number and "1" is the
> > >> order_line_number,
> > >> > but the query generator has swapped them. I've verified the joins
> in
> > >> the
> > >> > modeler (and 4.1 works).
> > >> >
> > >> > Thanks,
> > >> >
> > >> > Lon
> > >>
> > >>
> > >>
> > >> --
> > >> Best regards,
> > >> Nikita Timofeev
> > >>
> > >
> >
>
Re: Another regression in 4.2
Posted by Arseni Bulatski <ab...@objectstyle.com>.
Hi Lon,
I looked through your issue and tried to reproduce it.
As I understand you have table with char PK.
I run it on both 4.1 and 4.2 and have such results:
For 4.1 SELECT t0.OTHER_COL, t0.PK_COL FROM CHAR_PK_TEST t0 WHERE
RTRIM(t0.PK_COL) = ? [bind: 1->PK_COL:123]
For 4.2 SELECT RTRIM(t0.OTHER_COL), RTRIM(t0.PK_COL) FROM CHAR_PK_TEST t0
WHERE RTRIM(t0.PK_COL) = ? [bind: 1->PK_COL:123]
Maybe you can add some more details for it?
On Thu, Jul 18, 2019 at 7:47 PM Lon Varscsak <lo...@gmail.com> wrote:
> Hey Nikita, this is still a problem, but looks like it's happening on
> straight-forward fetches (possibly with "char" datatypes):
>
> SELECT DISTINCT [t0].[average_cost], [t0].[backorder_flag],
> [t0].[break_match_code], [t0].[case_location], [t0].[case_qty],
> [t0].[category_code], [t0].[cgs_gl_account],
> RTRIM([t0].[charges_group_code]), [t0].[composition_family],
> [t0].[composition_output_definition], [t0].[custom_vendor],
> [t0].[description], RTRIM([t0].[drop_ship_code]), [t0].[duties_percent],
> [t0].[duties_tax_cost_percent], RTRIM([t0].[envelope_item_number]),
> [t0].[expect_date], [t0].[first_sale_date], [t0].[freight_cost_percent],
> [t0].[inventory_gl_account], [t0].[lead_time], [t0].[license_required],
> RTRIM([t0].[market]), [t0].[material], [t0].[merchandise_cost_percent],
> [t0].[operator_message], [t0].[origin], RTRIM([t0].[part_number]),
> [t0].[personalization_flag], [t0].[primary_location],
> [t0].[print_specification], [t0].[print_template],
> RTRIM([t0].[procurement_code]), [t0].[qty_expected],
> [t0].[qty_on_backorder], [t0].[qty_on_hand], [t0].[qty_reserved],
> [t0].[qty_available], [t0].[return_gl_account], [t0].[sales_gl_account],
> [t0].[sales_unit], [t0].[serial_number_flag], [t0].[special_process],
> [t0].[status], [t0].[tax_flag], [t0].[tesla_qty_on_backorder],
> [t0].[tesla_qty_reserved], [t0].[unit_of_measure], [t0].[vap_cost_percent],
> RTRIM([t0].[vendor_code]), [t0].[weight], RTRIM([t0].[root_part_number])
> FROM [production.dbo.part] [t0] WHERE *RTRIM([t0].[part_number])* = ?
> [bind: 1->part_number:'120476']
>
>
>
> On Tue, May 14, 2019 at 10:47 AM Lon Varscsak <lo...@gmail.com>
> wrote:
>
> > Thanks!
> >
> > On Sat, May 11, 2019 at 5:04 AM Nikita Timofeev <
> ntimofeev@objectstyle.com>
> > wrote:
> >
> >> Hi,
> >>
> >> Fixed this, see [1]. Thank you for another catch!
> >>
> >> [1] https://issues.apache.org/jira/browse/CAY-2578
> >>
> >> On Mon, May 6, 2019 at 11:28 PM Lon Varscsak <lo...@gmail.com>
> >> wrote:
> >> >
> >> > Hey all,
> >> >
> >> > I have a join from order_detail_sales to continuity_detail based on
> >> > order_number and order_line_number. When fetching the to-one
> >> > getContinuityDetail I'm getting an error because the query generated
> is
> >> > swapping the keys:
> >> >
> >> > SELECT [t0].[intent_date], [t0].[line_end_date],
> [t0].[line_setup_date],
> >> > [t0].[next_ship_date], RTRIM([t0].[process_flag]),
> [t0].[reminder_date],
> >> > [t0].[reminder_days], [t0].[scheduled_shipments],
> [t0].[ship_frequency],
> >> > [t0].[order_number], [t0].[order_line_number] FROM
> >> > [production.dbo.continuity_detail] [t0] WHERE *( ( [t0].[order_number]
> >> = ?
> >> > ) AND ( [t0].[order_line_number] = ? ) ) [bind: 1:1, 2:57874832]*
> >> >
> >> > In reality "57874832" is the order_number and "1" is the
> >> order_line_number,
> >> > but the query generator has swapped them. I've verified the joins in
> >> the
> >> > modeler (and 4.1 works).
> >> >
> >> > Thanks,
> >> >
> >> > Lon
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> Nikita Timofeev
> >>
> >
>