Hi Armin Thanks for the response -- will the sequence number be reused? How is mapping 2 or more classes onto a single table any different in sequence generation terms from mapping to several tables? The changes I made basically "should" (!) go back up the hierarchy to the top level class so in the case of the examples in the unit tests (classes AB, A and B and B1) the sequence manager should always use the fq class name of AB...or am I missing something?
Thanks Mark -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 16, 2002 1:44 PM To: OJB Users List; [EMAIL PROTECTED] Subject: Re: SequenceManagerHiLoImpl and multi-level extents (part II a fix?) Hi Mark, currently I start to integrate your fix. IMHO your fix (use fq classname as seqName) causes a new problem, described by Matthew in the source code of SequenceManagerHiLoImpl: <snip> /** * MBAIRD * Should not use classname for the sequenceName as we will end up * re-using sequence numbers for classes mapped to the same table. * Instead, make the FullTableName the discriminator since it will * always be unique for that table, and hence that class. If we have two classes A,B mapped to the same table T, A extends C, B extends D (C, D mapped to T). Now we get a problem when using fq classname as sequence name. Why not use a combination of both (tablename and fq classname) to build a sequence name? String seqNamePartClass = targetClass.getName(); String seqNamePartTable = brokerForClass.getClassDescriptor( (Class) (brokerForClass.getClassDescriptor(targetClass) .getExtentClasses().get(0))) .getFullTableName(); seqName = seqNamePartClass + SEQ_NAME_SEPARATOR + seqNamePartTable; What do you mean? regards, Armin ----- Original Message ----- From: "Mark Rowell" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, October 15, 2002 4:42 PM Subject: SequenceManagerHiLoImpl and multi-level extents (part II a fix?) > Hi > > Further to my earlier email I think I have managed to fix this (at least it > works for my problem and the unit tests > all run succesfully on SQL Server, except the ones that fail on foreign key > constraints in the distribution > FYI: > - testGetB (relatedA not found) > - testDeleteB > - testCreateWithoutRelatedObject > > Anyway, onto the fix. I had to make minor changes (mostly to do with > recursion) in 3 classes: > > - SequenceGenerator > - SequenceManagerHiLoImpl (tat is the only sequence tye I use) > - DescriptorRepository > > They are attached. My changes are prefixed by a comment line > > // Note! MAR > > One change to note is that rather than using teh table name in the > OJB_HL_SEQ table I now use the last 175 chars of the > fully qualified class name (if the name of the class is more than 175 chars > long) of the top level extent. > E.g. in my previous email the interfacve at the top of my hierarchy is > com.credittrade.instrument.Instrument and this > is now used in the OJB_HL_SEQ table. > > > These source files are from the 0.9.6 release -- I am pretty sure they have > not changed in 0.9.7 (which I jave not yet built) > I woudl be grateful if someone could merge these changes into the source > tree if > > (a) they are correct > (b) and they have no unforseen side-effects e.g. performance and so > on > (c) and if you want to! > > Many thanks > > Mark Rowell > > ---------------------------------------------------------------- > Mark Rowell > CreditTrade > > T: +44 (020) 7400 5078 > M: mailto:[EMAIL PROTECTED] > > > > CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. > > Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. > > The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice. ------------------------------------------------------------------------ -------- > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> CreditTrade Limited is regulated by the FSA. (c) CreditTrade 2002. All rights reserved. The information and data contained in this email is provided for the information purposes of the addressee only and should not be reproduced and/or distributed to any other person. It is provided without any warranty whatsoever and unless stated otherwise consists purely of indicative market prices and other information. Any opinion or comments expressed or assumption made in association with the data or information provided in this email is a reflection of CreditTrades judgement at the time of compiling the data and is subject to change. CreditTrade hereby makes no representation and accepts no responsibility or liability as to the completeness or accuracy of this email. The content of this email is not intended as an offer or solicitation for, or recommendation of, the purchase or sale of any financial instrument, or as an official confirmation of any transaction, and should not be construed as investment advice. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
