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
