Ok I'll make change everything to 30 for startes. -dain
Karl Koster wrote: > Dain, > > Most DB's have maximum object names of 30 characters. I know this applies to > Oracle, Postgresql, Sybase, and MS SQL Server. > > Karl Koster > [EMAIL PROTECTED] > Sempra Energy Trading > 203-355-5182 > > -----Original Message----- > From: Dain Sundstrom [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, February 27, 2002 11:27 AM > To: JBoss-dev > Subject: [JBoss-dev] Re: [ jboss-Bugs-516835 ] pk constraint name too > long > > > What is the maximum length of an alias in Oracle (or any other dbs that > we support) I did add an alias-max-length in the > standardjbosscmp-jdbc.xml file, but I set all of them to 32 for starters. > > -dain > > [EMAIL PROTECTED] wrote: > > >>Bugs item #516835, was opened at 2002-02-13 00:27 >>You can respond by visiting: >> >> > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516835&group_id= > 22866 > >>Category: JBossCMP >>Group: v3.0 Rabbit Hole >>Status: Open >>Resolution: Accepted >>Priority: 5 >>Submitted By: Georg Schmid (giorgio42) >>Assigned to: Dain Sundstrom (dsundstrom) >>Summary: pk constraint name too long >> >>Initial Comment: >> >>RH 20020212, W2K, Oracle 8.1.7. >> >>Supplying a broken jbosscmp-jdbc.xml reveals, >>that the CMP pk constraint name generation code does >>not take into account the maximum identifier length >>allowed by the underlying data source. >> >>It seems as if EB and pk field names are simply >>concatenated without looking at the length of the >>generated identifier. >> >> >>Georg >> >>---------------------------------------------------------------------- >> >> >> >>>Comment By: Georg Schmid (giorgio42) >>> >>> >>Date: 2002-02-27 08:15 >> >>Message: >>Logged In: YES >>user_id=437570 >> >> >>I already know several places where I can >>put the great new EJB-QL compiler and its "order by" >>capability to good use :), but in the meantime... >> >>>From the following custom finder query (two String params): >> >> <ejb-ql> >> select object(schedule) >> from ScheduleTable schedule, >> IN(schedule.equipments) equipments >> where schedule.maintenance.id = ?1 >> and equipments.id = ?2 >> </ejb-ql> >> >>the following SELECT is generated (slightly formatted): >> >>SELECT t0_schedule.ID >> FROM SCHEDULE t0_schedule, >> EQUIPMENT t2_equipments, >> MAINTENANCE t1_schedule_maintenance >> WHERE t1_schedule_maintenance.ID = ? >> AND t2_equipments.ID = ? >> AND (t0_schedule.FK_MAINTENANCE_ID=t1_schedule_maintenance.ID >> AND >>t0_schedule.ID=t3_schedule_equipments_RELATION_.FK_SCHEDULE_ID >> AND >>t2_equipments.ID=t3_schedule_equipments_RELATION_.FK_EQUIPMENT_ID) >> >>Two problems: >> >>- the identifier >>t3_schedule_equipments_RELATION_ is too long (Oracle error >>ORA-00972). >>- this identifier is missing in the FROM clause (that's >>a different bug). >> >>This query worked until yesterday. >> >>So if this alias name is shortened to something Oracle >>is able to handle, the semantic checker will complain. >> >>I guess, in general the length of relationship table alias >>name should be less than >> max(length(ATableName), length(BTableName)) >>(or <= max(length(A_AbstractSchema),length(B_AbstractSchema))) >>to be on the safe side. >> >>Georg >> >> >>---------------------------------------------------------------------- >> >>You can respond by visiting: >> >> > http://sourceforge.net/tracker/?func=detail&atid=376685&aid=516835&group_id= > 22866 > > > > > _______________________________________________ > Jboss-development mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/jboss-development > > > ********************************************************************** > This e-mail contains privileged attorney-client communications and/or confidential >information, and is only for the use by the intended recipient. Receipt by an >unintended recipient does not constitute a waiver of any applicable privilege." > > Reading, disclosure, discussion, dissemination, distribution or copying of this >information by anyone other than the intended recipient or his or her employees or >agents is strictly prohibited. If you have received this communication in error, >please immediately notify us and delete the original material from your computer." > > Sempra Energy Trading Corp. (SET) is not the same company as SDG&E or SoCalGas, the >utilities owned by SET's parent company. SET is not regulated by the California >Public Utilities Commission and you do not have to buy SET's products and services to >continue to receive quality regulated service from the utilities." > ********************************************************************** > _______________________________________________ Jboss-development mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jboss-development
