well, i will give it a shot... the advantage of a grab size is speed. you dont have to go back to the db for every id, only when you hit the grab size. disadvantage, you waste a few numbers (who cares)... someone correct me if i am wrong :)
-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 4:27 PM To: OJB Users List Subject: RE: OJB vs Hibernate Same here. I guess that's just a bad example I gave. I just wanted to see what the advantage and disadvantages are. Really the only thing I can say bad about OJB so far is that is docs aren't done yet and the OQL is not all there. That may have changed by now. It's been awhile since I've looked at is. I help work on the SAPDB support for OJB for awhile. My name used to be in the code for the platform specific class for sapdb. I guess I just need to look at what's been done so far. Thank You, Justin A. Stanczak Web Manager Shake Learning Resource Center Vincennes University (812)888-5813 "Lance Eason" <[EMAIL PROTECTED] To: "OJB Users List" <[EMAIL PROTECTED]> erwire.com> cc: Subject: RE: OJB vs Hibernate 03/31/03 04:15 PM Please respond to "OJB Users List" Actually Oracle's sequence implementation does exactly the same thing. It has a fetch size for the sequence and if this is larger than 1 a restart of the server will leave a gap. I guess this isn't a big deal to me. Even if I was restarting the server after every key generation I've only reduced my space of keys by an order of magnitude and I've got many, many more orders of magnitude available than I ever expect to have records (unless my system is going to live under heavy load for millions of years :-) ). Realistically I expect my servers to be restarted fairly infrequently compared to the number of keys generated so the lost numbers is a pretty insignificant fraction. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 3:03 PM To: OJB Users List Subject: RE: OJB vs Hibernate It doesn't really hurt anything, but why throw away numbers. Why waste a key id number. I just makes the id number grow faster. I just find it to be sloppy. I've never see a database that skips like that. I don't restart the production app very often so there's no big deal there. Do you not see that as a waste to increment the numbers like that? Thank You, Justin A. Stanczak Web Manager Shake Learning Resource Center Vincennes University (812)888-5813 "Lance Eason" <[EMAIL PROTECTED] To: "OJB Users List" <[EMAIL PROTECTED]> erwire.com> cc: Subject: RE: OJB vs Hibernate 03/31/03 03:38 PM Please respond to "OJB Users List" Just as a philosophical question why do you care that it jumps the count by 10 when you restart? The idea of a meaningless primary key is simply to provide a unique identifier for the row. What does it matter whether it's continuous or not? -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Monday, March 31, 2003 2:33 PM To: [EMAIL PROTECTED] Subject: OJB vs Hibernate I'm guessing someone has already asked this, but I'm going to ask again. I'm currently using OJB. I like OJB just fine, except the auto increment part. Every time I restart my web app it jumps the count up ten. I know why it does that and I'm guessing that if I set the increment count to one instead of ten it would fix this. I'm not really sure I like all the tables you have to create to run the ODMG part. I was thinking of switching to Hibernate. I've looked at it some and it looks like it does the same thing except the JDO. It does say it supports ODMG. Any input would be great. Hey, maybe I'm just not using OJB right. Thank You, Justin A. Stanczak Web Manager Shake Learning Resource Center Vincennes University (812)888-5813 --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
