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 > >>>>>>> > >>>>>> > >>>>> > >>>> > >>> > > > >
