----- Original Message -----
From: Jim Archer <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: Ralph Jensen <[EMAIL PROTECTED]>
Sent: Tuesday, May 08, 2001 4:03 AM
Subject: Re: [JBoss-user] EJB question
> Hi Ralph...
> ...
> > 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.
As danch said: ejbCreate needs to know it, because it must return it,
according to spec. What actually happens, if it doesn't?
>>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.
>
I was thinking of a function like sendContribution( Object content,
clientID, somethingElse ); or possibly two: sendText( String text,
clientID, ... ) and sendBinary( Object content, clientID, ... ) if I want
to have different tables for text and non-text contributions.
The question now is, where these methods should be located. If I understand
you correctly, you say that's a session bean.
> You can do this with ny field, of course, although I'm not exactly sure
how
> it would work with a BLOB.
>
The searching then would have to be done depending on the choice above.
> > 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...
>
Somebody has to create a conference. That is done by entering a record into
a database, with fields like topic, starttime, endtime and other
configurable items, plus a 'status' column that tells if the conference is
in process or not. The collaborative session is then that one record
represented by one entity bean.
> > Conference. It represents a record in a table called conferenceTable.
>> ...
> >
> > 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:
>
I meant to add the one or two contribution methods to the above entity bean
representing the conference.
> 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)
>
So you mean, the contribution methods would go into a session bean?
The session bean would check, if the conference is in process by accessing
above ConferenceBean, (then check some other stuff accessing some other
beans ...) and THEN: write the contribution into a table without using an
entity bean in order to circumvent the primary key issue, which started
this discussion. Meaning, if I use and ejbCreate(...) method that ejbCreate
needs to return the primary key, but I want the database to asign it and
there is no portable way to get it into the bean.
> 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.
>
I was thinking of two contribution types because a participant can send
either text or non-text. Having one contribution type seems to indicate
that I each record needs to have columns for text and BLOBs while at any
time only one will be used.
> 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.
To make a new EJB representing the contribution created the problem in the
first place. I would have to call ContributionHome.create(...) or so, which
requires and ejbCreate(...), which needs to return the primary key. So I
want to INSERT the contribution without using a bean. If I later need to
list contributions I would of course use EJBs with custom finder methods.
> 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.
I will use BMP for now.
>
> > 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.
Exactly.
> 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.
>
Right, but again, for the purpose of creating the data I'd like to do it
without an ejbCreate(...). Handling existing data would be done with beans.
> 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.
>
Why would I be tied to a database? All I need is that the database supports
something like the autoincrement feature. I don't want to read the key back
at creation time, and later I use custom finders with other fields. I just
want to avoid the overhead from using multiple fields for the primary key
(which is probably impossible anyway due to the nature of the data) or from
creating a unique key, when the database can do it best.
> 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
>
>
Thanks for all the help :-)
Ralph
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
