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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >>> 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 < >> [email protected]> >>> 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 <[email protected]> >>> 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 < >>> [email protected] >>>>>>> >>>>>> 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 < >> [email protected]> >>>>>>> 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 < >>> [email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> On Sat, May 11, 2019 at 5:04 AM Nikita Timofeev < >>>>>>>> [email protected]> >>>>>>>>> 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 < >>>>>> [email protected]> >>>>>>>>>> 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 >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >>> >>
