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 <and...@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 <abulat...@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.varsc...@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 <abulat...@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.varsc...@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.varsc...@gmail.com> >>>>> wrote: >>>>> >>>>>> Thanks! >>>>>> >>>>>> On Sat, May 11, 2019 at 5:04 AM Nikita Timofeev < >>>>> ntimof...@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.varsc...@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 >>>>>>> >>>>>> >>>>> >>>> >>> >
