cayenne-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lon Varscsak <lon.varsc...@gmail.com>
Subject Re: Another regression in 4.2
Date Wed, 24 Jul 2019 20:12:34 GMT
Ah, gotcha.  thx

On Wed, Jul 24, 2019 at 12:01 PM Andrus Adamchik <andrus@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 <lon.varscsak@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 <andrus@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
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>
> >>>>
> >>>
> >>>
> >>
>
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message