| |
| |
| |
|
Page: 1 2 3 4
Comments:
<0> so you don't have to define a second field like "itemKey"
<0> and map it with @basic
<0> remove this part
<0> keep your many-to-one
<1> kinematix: ok, then I don't have the extra field (instead of the itemKey field, I not have just the 'item_itemKey' field in 'price'
<0> but drop your field itemKey and its annotation (@basic)
<0> you should only have
<0> itemKey
<0> but my question is
<0> do you get hte point
<0> you must understand, not simply make it work
<1> kinematix: ah, yes, now it looks right
<1> kinematix: thanks ;)
<0> do you understand why ?
<0> in fact, your "item" reference from the price object, mapped with the many-to-one, is the one that creates the itemKey table
<1> yeah, I thought I had to link to identically named keyfields (itemKey) in both tables, whereas I don't, I only name the one in the many table
<0> you defined it with "mapped_by"
<0> look
<0> you can still define the one-to-many
<0> the one-to-many will not generate any new column
<1> hence I had an extra reference in the price table, and misstakenly though that the item_itemKey was the extra one, not the one I had defined myself
<0> it should have its key being "itemKey" from your price table
<0> so he knows he will get the prices for an item doing a select from price where itemKey =
<0> conclusion: never define a field which is managed
<0> one point however
<1> Indeed, I now have both the onetomany and manytoone
<0> but you may be lost here
<0> one reason to
<0> have a itemKey field separately
<0> is to have the opportunity to say, add, remove, update, query a price based on its itemkey
<0> without necessaraly having to have a reference to an item object
<0> so you could do something like
<0> price.setItemKey( "mykey" );
<0> session.save( price );
<2> hmm, hibernate looks very involved
<0> but for that
<0> you must define the itemKey field just like you did
<1> smsie: setting up mappings and such is. the point is to make the actuall code simple though ;)
<0> but map the many-to-one with the attributes: insert="false" and update="false" to let it know that
<0> it shouldn<t generate an extra column and should rely on the other property (itemKey, explicitely defined) to accomplish CRUD operations
<0> then, in the setItem( Item item ) method you have on price, you can do something like : if( item != null ) setItemKey( item.getId() );
<0> that's a trick I use
<2> wlfshmn: just looking at the docs
<2> I would guess that much of the setup can be abstracted away
<0> wlf: you follow?
<1> smsie: you can supposedly get hibernate tools to generate configurations for you from an existing database if that is your preference, but I've never tried, and I seem to recall it takes a JDBC driver that properly implements the metadata objects
<1> kinematix: I believe I do
<2> wlfshmn: yeah. I'll look further
<0> wlfshmn: any other question?
<1> kinematix: not at the moment, no. I'll be adding a few more of these manytoone pairs
<0> you should add me in your msn and use me for all your hibernate questions, hibernate is a monster and it takes time to learn and understand, but once you master it, you won't want to work with jdbc directly or write any sql anymore
<1> I only have one hibernateified project other than this plaything, and that is simple enough that there is only a single history table with no complications in it whatsoever ;)
<1> kinematix: If you are willing to share your MSN, that would be very nice
<2> I have a need for an incrementing value in a threadsafe and persistent way
<2> is hibernate better than oracle for that?
<0> smsie: hibernate can't be compared to oracle
<1> smsie: hibernate is not a database
<2> at the moment I have a single row table and access it via a singleton
<0> smsie: you want concurrency management in fact
<0> locking, pessimistic or optimistic
<2> kinematix: yeah, I'm doing that...it just feels awkward
<1> I've become alergic to autoinc or similar identity columns in the past few years
<1> it makes it bloody hard to copy and merge parts of databases, which is half of what we do here ;)
<0> wlfshmn: but also, if you declare that with hibenrate
<0> when calling session.save() hibernate will issue the sql insert right away
<0> to recuperate the generated id
<0> and you cannot have batch inserts
<1> my keys here are GUIDs I create myself, which shoes my MS heritage
<2> wlfshmn: oh, I don't do that. I just have a syncronised method in the singleton which increments the value in the database. It's fairly simple and it does work (at least, none of my tests have been able to break it :)
<0> which is a neat disadvantage
<0> if you are importing alot of data
<0> smsie: explosive!
<0> smsie: bad!
<0> smsie: it doesn<t work in a multi-user environment
<1> smsie: in oracle we maintain a sequence for log table IDs (which aren't sunchronized) and some minor PL/SQL to acess it. BUt it's only used from within triggers I believe
<0> at least not in a client-server architecture
<2> kinematix: it doesn't have to...
<2> kinematix: the alternative is to keep track in a file, which is a ****y idea
<0> no
<0> the alternative is to use a good generator
<2> and suffers exactly the same concurrency issues
<0> that generate random values based on
<0> the machine timer, the machine IP
<0> a random seed
<2> kinematix: a random value is NOT suitable
<0> and a contextual object
<2> kinematix: I need the next value froim the last used
<0> smsie: what happens if someone delete a row
<1> oracle sequences are guaranteed atomic though, I believe
<0> you will get ahole anyway
<2> kinematix: there's only one row
<0> yes, using a database managed id
<0> is the best approach
<0> to be sure
<0> you have unique ids
<0> but as I said, it causes problem with the domain model design pattern
<1> yeah, ***uming as before, that you always have access to said source of numbers ;)
<2> let me explain further...
<2> we have a pathology system, which needs order numbers for every test
<0> because it is hard to have batching and recuperate the ids (not possible in hibernate, problematic in jdbc)
<2> the order numbers must be unique
<0> but it is the safest way
<0> so if you don't need m***ive inserts (batching) I would choose this approach
<2> so we need to keep a record of which order number is the next one
<1> kinematix: do you have any suggestions of must-read literature in the hibernate/java/databases combo?
<2> that's all that's needed. A simple record of "this is the next number to use"
<0> smsie: why not use oracle sequences then?
<0> wlfshmn: I ***ume you have good database knowledge (transactions, relational modelization)
<1> kinematix: not nearly as good as it should be
<0> then for hibernate, simply refers to its official doc and don<t read it in a linear way
<0> simply seek the info you want, coz hbienrate has so many features
<1> kinematix: I know the basics and what I've activly run into and been forced to learn, but I lack a broader knowledge
<2> kinematix: good suggestion
<1> kinematix: indeed, that is what I am currently doing
<2> I'll look into that
<0> smsie: that's the safest way
<0> but do you need to insert lot of entities (rows) in this table?
<0> like blocks of 1000
<0> etc
<0> or you simply insert rows from time to time, one by one ?
<0> wlfshmn: so you are doing right
<0> wlfshmn: remember sessions and thus transactions aren<t thread=safe and use hte hreadLocal pattern
<0> use the ThreadLocal pattern to get a new hibenrate session for each thread
<0> also, isolate your discussion with the database between transactions, ALWAYS
<0> for reading from it, for writing to it
<1> kinematix: ah, I'm not sure I do it for reading currently
<0> you should
<0> a hibernate commit is more than a simple transaction commit
<0> keep this in mind
<1> ah, I am.
<0> and never keep a session open for a long time (like, if user interactino is necessary
<1> I'm not so sure I use the session in a threadsafe manner however
<0> wlfshmn: you dont really need the thread local pattern, but it makes sure you never use a session between threads
<0> if you do a sessionFactory.openSession() for each thread, you are ok
<0> wlfshmn: but make sure you -never- keep a session open
<1> kinematix: getSessionFactory().getCurrentSession() it seems
<1> but yes, closing as soon as possible I do. It's fairly well incraned in the spine to release resources as soon as humanly possible
<1> s/incraned/ingrained/
<0> Session session = null; Transaction tx = null; try { session = sessionFactory.openSession(); tx = session.beginTransaction(); /* your persistence code goes here */ tx.commit() } catch( HibernateExceptione ) { tx.rollback() } finally { session.close(); }
<1> or.. maybe not.. ah, whatever ,)
<0> that's the way to go
<1> ok then, so I replace getCurrentSession with openSession
<0> well
<0> wait
<0> im not aware of getCurrentSession
<0> maybe they integrated the ThreadLocal pattern
<0> direclty in hibenrate
<0> let me read
<1> kinematix: Quite possible. I copied pieces of that from the hibernate docs
<1> and they did change between 3.0 and 3.1 in that regards
<1> but as I said before, I am not far along enough to actually run hibernate -code-, and as such, the little code I have usign hibernate is in sorry disrepair. All I can tella botu it currently is that it compiles ;)
Return to
#java
or
Go to some related
logs:
#MissKitten
sweinhocks
#chatzone
#teens
#javascript
wine ole error 80004001 fix
wgetrc ip4
#c
xine windows-all
WPC54Gv3 Fedora
|
|