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 <abulat...@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 <and...@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 <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 > > >>>>>>> > > >>>>>> > > >>>>> > > >>>> > > >>> > > > > > > > >
