Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsWhite Papers
Discussion GroupsFirst AidDatabasesJavaBeansGUIJava 3DVirtual MachineCORBASecurityToolsGeneral
Java DirectoryOpen Source ProjectsSample Book ChaptersUser GroupsWeb Resources
Related Topics
Databases.NETMore Topics ...

Java Forum / Databases / December 2007

Tip: Looking for answers? Try searching our database.

Beginner question about JDO best practice

Thread view: 
Sven - 20 Dec 2007 13:26 GMT
Dear all,

this is the first time I'm using JDO/ORM (the JPOX implementation) and
so have a question about best practice.

Let's assume we have a class "Tag" with the only property "String
name" and according setters and getters. The related table has two
columns "PRIMARY BIGINT tag_id" and "UNIQUE VARCHAR name". Note that
the column "name" is unique.

Let's further assume that we manually create some Tag objects during
application runtime. We now want to persist these objects but we don't
care if they are already persisted in the database. If this is the
case, JDO should just attach the object to the database instance. What
is the best practice to accommodate this? Do I have to manually check
every object for existence first? I would like to avoid this.

Let's say the tag "coffee" is already available in the database. I'm
looking for something which works like this:

--8<-snip->8--

Tag tag1 = new Tag( "java" );
Tag tag2 = new Tag( "means" );
Tag tag3 = new Tag( "coffee" );

// no problem
pm.makePersistent( tag1 );

// no problem
pm.makePersistent( tag2 );

// throws SQLException DUPLICATE KEY but should just attach/update
tag3 to database instance
pm.makePersistent( tag3 );

--8<-snip->8--

Thanks for any hint!
Dyreatnews@sun.com - 20 Dec 2007 15:02 GMT
> Dear all,
>
[quoted text clipped - 31 lines]
> tag3 to database instance
> pm.makePersistent( tag3 );

But presumably the 'name' column is declared 'UNIQUE' for a reason?
Allowing you to just add tag3 would violate the unique-ness,
wouldn't it? If you don't really need them to be unique after all,
shouldn't you change the table definition to reflect that?

Signature

dt

Sven - 20 Dec 2007 15:53 GMT
> But presumably the 'name' column is declared 'UNIQUE' for a reason?
> Allowing you to just add tag3 would violate the unique-ness,
> wouldn't it? If you don't really need them to be unique after all,
> shouldn't you change the table definition to reflect that?

To simplify matters I didn't explain the whole situation but I guess
this is necessary now:

Let's say we have another class, for example a "BlogEntry" class,
which contains - among other things - a Set of Tag objects. Since
there can be many BlogEntry and Tag instances I want the tags to be
unique in the database scheme. blog entries and tags are related to
each other via a join table which contains the columns "blog_id" and
"tag_id".

What I was hoping for is that JDO automatically handles the uniqueness
of tags when persisting a BlogEntry object with n Tag objects and
inserts the right ids into the join table.
Sven - 20 Dec 2007 18:24 GMT
Update: I've created a method which returns a Tag object from the
database based on a name, if available. This method detaches the Tag
object. Also the Tag class was not defined as detachable before which
I changed.

Now, when I persist a BlogEntry object which contains new and existing
Tag objects no more exception occurs, but the existing Tags are not
joined to the BlogEntry object in the join table.


Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.