Hi Jin, MySQLSequenceManager was not shipped with 0.97. Next version of OJB will include this implementation. Currently the sequence package was under some development. If you want to check out version from CVS try revision 1.2 (should be compatible with 0.97)
regards, Armin ----- Original Message ----- From: "Jin Bal" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Monday, November 18, 2002 9:33 PM Subject: Re: SequenceManager- legacy data compatibility > Hi Travis, > > That sounds like it should do the trick. > > I was trying to avoid using the autoincrement to increase portability but i > think it is now apparent that between ojb and it's various implementations > and the particular db it *should* be possible to migrate without too much > probs. > > Is the MySQLSequenceManager the one in cvs? if so which build are you > using - 0.9.7 doesn't seem to have it (correct me if i'm wrong). > > Many thanks > > Jin > ----- Original Message ----- > From: "Travis Reeder" <[EMAIL PROTECTED]> > To: "OJB Users List" <[EMAIL PROTECTED]> > Sent: Monday, November 18, 2002 4:06 PM > Subject: Re: SequenceManager- legacy data compatibility > > > > Hi Jin, > > > > I am also in the same situation and I have made a MySQLSequenceManager > that > > you can use that will use the auto_increment column in the db, and does > not > > use the ojb_seq tables. > > > > So in your OJB.properties, change the SequenceManagerImpl (or whatever the > > property is) to the MySQL one and give that a try. Then you should be > able > > to continue using your non-ojb code with the new ojb code. > > > > Travis > > > > > > > > ----- Original Message ----- > > From: "Jin Bal" <[EMAIL PROTECTED]> > > To: "OJB Users List" <[EMAIL PROTECTED]> > > Sent: Monday, November 18, 2002 8:00 AM > > Subject: SequenceManager- legacy data compatibility > > > > > > Hi All, > > > > The database tables(MySql 4) for the application I am currently developing > > are currently being populated via > > non OJB means i.e. not using the ojb to generate primary key id's. > > (basically a standalone application/sql client). The application uses OJB > > to query the DB. > > > > This approach is currently more time/workload efficient however we *will* > be > > porting this functionality over to the web-app which will then use OJB as > > the peristence mechanism. > > > > My question/s are : > > > > 1) will OJB's Sequence manager/internal tables be able to cope with the > > fact that there are externally generated id's in some/all of the tables > and > > be able to integrate smoothly. > > > > 2) is it possible for the standalone application to use the ojb_seq and > > ohb_hl_seq directly. Would that make my life easier? I am assuming it is > > not much more complicated than getting the last value and adding n to it. > > Please correct me if I'm wrong > > > > 3) has anybody used this approach (i am aware that it is not ideal but it > is > > most convenient for now) > > > > many thanks for your time > > > > Jin > > > > > > -- > > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
