Hi Ralph...
--On Monday, May 07, 2001 4:36 PM +0800 Ralph Jensen <[EMAIL PROTECTED]>
wrote:
> That probably means that java.sql can't do it. Even if it could, that
> wouldn't solve the problem with non-relational databases.
Right.
> Actually, the original question came up in this context:
>
> I am developing a collaborative application which stores the contributions
> of participants in a database. These contributions could be text messages
> or other objects, stored as blobs. None of the individual elements will be
> useful as a primary key and thus I thought, why not let the database
> create a unique key. My original question arose from the fact that an EJB
> needs to know the primary key in order to return it and my assumption
> that I have to call create(...) on an EJB in order to insert new data.
I'm not sure what you mean by the EJB needs to know the primark key to
return it... All your entity beans need to have a primary key, but your
home interface can have finder methods that don't need the primary key. If
you have different people making contributions, then you are probably (my
poor assumption) going to need a way to tell who made what? So you can
search by the username field or something like that to get vack a
COllection of all the entity beans that have that username.
You can do this with ny field, of course, although I'm not exactly sure how
it would work with a BLOB.
> But I could also do it this way:
>
> I have an EJB which represents one collaborative session - let's call it a
I'm not sure what a collaborative session is - one record or many? I think
you mean it would be a bunch of entity beans...
> Conference. It represents a record in a table called conferenceTable. In
> creation of this conference, all the issues discussed concerning
> uniqueness of keys are relevant. But because I create that only once I
> may even trouble the creator to enter a unique conference id. (Don't we
> all know it: "Your userid isnt unique. Try again. Suggestion:
> 'mk$rtio237k'. :-)". Then, during the session, participants will add a
> lot of information and that's where I want to minimize the effort for
> creating unique keys.
>
> I can add methods to my Conference bean like Conference.sendText( text,
> client ) or Conference.sendOtherStuff( blob, client ) and then within
> these methods do INSERTs into another table which hold the contributions
> of participants, somehow like this:
First, the issue of an API for the other code. Generally, a good EJB design
will use a session bean to access entity beans. Your busines logic would go
into the session bean, so methods that create new data, manipulate existing
data and so on would go here. This presents a nice API to the rest of the
code that you can change the implementation of.
So the session bean might have a method like sendText(text, client)
Now, the issue of the data and how its related. It seems like you are
talking about having two entity beans. One to represent the person (or
client?) making the contribution. This EB might have fields to identify
that person. Next, you have an EB to represent the contribution. This EB
might have a field to home the contribution, like a BLOB field. It would be
easy if you hade only one contributiun type, but if you have multiple types
(text, binary) you may want to look at multiple EBs for each type.
So, your session bean would be handed the user id of the contributor and
the contribution and told to make a new EB to represent the contribution.
You would then find the EB for the contributor, get its remote inteface
(using a finder from its home object) and give the remote interfce to the
contribution EB to relate the two.
EJB 1.1 does not handle these things very well if your using CMP, but thats
being fixed in EJB 2.0.
> That table could be created with an AUTOINCREMENT (or similar, depending
> on the database) for the primary key and thus primary keys are generated
> transparently by the database during the INSERT. But I don't need to know
> it, because the INSERT is not performed in an ejbCreate() method and
> doesn't need to be returned.
Probably, you might want to look at using BMP for this contribution bean.
Under BMP, you write all the database code with JDBC. When the bean is
created the create method you wrote is called. You could create the record
and let your database init the autoincrement field, then read it back.
Also, you would handle the relationship using the PK rather than a
serialized remote interface.
But I would not recomend that at all. I would recomend that you use a
unique key genertor to create your key. If you don't you'll be heavily tied
to whatever database you write this for. The java.rmi.server.UID class will
generate a unique key for the machine your using, and you can add the IP
address for global uniqueness.
If your just starting pout with this, you may want to look at EJB 2.0. The
spec is not final yet, but its close. EJB 2.0 CMP has vastly improved
support for relationships. You can get a plugin for jBoss at
http://www.mvcsoft.com
Jim
********************************************
I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I -
I took the one less traveled by,
And that has made all the difference.
- Robert Frost, 1916
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
