Ah, gotcha. thx On Wed, Jul 24, 2019 at 12:01 PM Andrus Adamchik <and...@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.varsc...@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 < > 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 > >>>>>>>>>> > >>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>>> > >>> > >>> > >> > >
