Hi Paolo, even though what you want is possible with Empire-db, it is not the recommended approach. Your desire to obtain a List<DBRecord> is more the way traditional OR-Mappers work and that I criticize: They usually force you to work with data bean objects that match a record of the database table (full entity beans) even though it is in most cases (as with almost every list) neither necessary nor required. Especially when you have user interaction then a list you present to the user rarely shows a single table with all its columns.
For a better understanding I recommend reading the following article http://incubator.apache.org/empire-db/empiredb/hibernate.htm especially the section "Dynamic queries: The select dilemma" So what I recommend is the following: 1. Use DBCommand and DBReader to obtain and present a list to the user. Select the primary key and only columns that you want to display to the user. You may use reader.getBeanList() to obtain a list of traditional Java Beans for your list display needs. 2. If the user selects a in individual record, read it user DBReader.read(). The entire record then will be fetched from the database and you may change and update it. Then the user may select and change another record. Alternatively if multiple records are to be changed on one click of a button, then do the following: - Perform a new query for all records that need to be changed and iterate though them using a DBReader. - Initialize a DBRecord object for the current row using initRecord() - With the DBRecord change the value and call update(). - Continue with the next record. Regards Rainer Paolo Predonzani wrote: > Re: reading and updating records > > Hi Rainer, > Thank you for the prompt reply. > I will certainly look closer at the example applications. Below I reply > quicky with some first impressions. > > In order to read a record into a DBRecord object, you must supply it's > > primary key to the read() method. > > > > A DBReader on the other side is used to obtain and iterate through > > information about objects (or records) and > usually does not correspond to > > the record of a table - like with a query that contains only selected > > columns as > well as joins to other tables. Hence a DBReader only provides > > read only access to the underlying data (through > the RecordData interface > > which both DBReader and DBRecord implement). > > > Agreed that some projections (in relational terms) make a result set > read-only. > However a SELECT that fetches all the columns - including PK - on a > single table is an updatable view, at least theoretically. > So in the general case I agree that a DBReader returns a read-only > RecordData. > But in some cases that RecordData object should very legitimately be a > writable Record. > > A typcial real world situation is that a user enters search criteria for > > which a list of matching items is presented to him. He then selects the > > item (record) he is looking for and changes some of its values. In this > > case you work with a DBCommand in conjunction with a DBReader to provide > > the list that you display to the user. The list should contain the primary > > key of the underlying records. When the user selects a particular record it > > is read using the primary key into a DBRecord object then changed and > > updated. The same procedure is repeated for all other records. > > When I take the PK from the DBReader and use it in read(... Object[] pk > ...), does the DBRecord reload the data from the database? > > > Although this is the most common approach, there is a second solution that > > might be more efficient in some cases: > > You may use a DBReader to query and iterate though a set of records and > > then upgrade the current row to a full DBRecord object which you can > > update. To achive this, all you need to do is to call the initRecord() > > method on the DBReader and supply the DBRecord object you with the use and > > the Table you want to work on. This will only work however if the query > > also contains the primary key column(s). > You can find an example for this in the bulkProcessRecords() method of the > advanced example (DBSampleAdv) from line 442. > > > I will look into the example. > This seems to be a streaming approach, i.e., data are processed as they > are iterated. > In many cases however a non-streaming approach is more advisable, or > just simpler (think SAX vs DOM for xml processing). > > From you description however I thinks that the first approach is more > > suitable for your problem. > > What is your problem with reading the record using the primary key that you > > obtained from the query? > > You probably need the primary key anyway in order to identify the right > > amount for a particular person, don't > you? > > > In my maybe naive view, I was expecting DBRowSet (which very correctly > abstracts tables, views and queries) to provide a method to access all > the records as a List<DBRecords>. > > This may sound strange for a DBTable, especially if it has many rows, > but... why not? > And for DBQueries it would be perfect for what I'm trying to do: > Command -> Wrap in MDView -> get all records -> present as visual table > to the user -> modify some data -> write back to the database. > > > For a complete solution that shows how to work with Empire-db in an > > interactive application I recommend > running the Struts2 web example. > > > > Has this been of any help to you? > > > Very much so. Thank you. > > Regards > > > Paolo
<<winmail.dat>>
