From: Jim A. <ji...@ar...> - 2001-05-09 19:57:39
|
--On Tuesday, May 08, 2001 11:17 AM +0800 Ralph Jensen <rj...@vr...> wrote: > As danch said: ejbCreate needs to know it, because it must return it, > according to spec. What actually happens, if it doesn't? Beats me... In EJB 2.0, we return null, although I think that changed in the latest PFD. So I have never tried it. > 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. Yes, its become accepted that session beans are generally used to create entity beans and manipulate them and otherwise hole business logic. Of course, there is nothing that stops you from using JDBC to access a database from a session bean if thats the best sollution for your app. > 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. OK, I see. > 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. This would work. But I would recomend using BMP and dealing with the primary key/sequence issue in the entity bean. > 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. Makes good sense. As I think about it, I guess all the types of contributions can probably be either binary data or textual data. >> 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. As we decided above, this would work, but my personal opinion is that two better options are 1) use an EB that uses BMP, or 2) use a unique key generator and not the database sequence type. But reasonable people can certianally disagree. > I will use BMP for now. A good choice. > 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. Yup, that will work. > 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. Well, I have worked mostly with PostgreSQL, MS SQL Server and Oracle. As I recall, all three had a different way of getting the value of the created serial field. But, as you say, your not interesting in reading that data back. I guess as long as your carefull with the BMP SQL, you'll not be tied to a database. Best of luck! Jim |