The edit-multiple-rows scenario happens any time you have to present an editable table. A popular Swing example explains this: http://java.sun.com/docs/books/tutorial/uiswing/components/table.html ... but also web components (in JSF, Wicket, etc) work on the same principle.
Basically, presentation components need a underlying object data model. It would be great if a DBRecord set could be that model. Also who works with conversations - a highly debated concept in web design - needs a "detached model" to store data until the end of the conversation, when the user finally presses the save button. A DBRecord with some improvements could fulfill that role too. I hope this clarifies my use case scenario. Regards Paolo On Sun, Apr 5, 2009 at 11:44 AM, Rainer Döbele <[email protected]> wrote: > Hi Paolo, > > great that you agree. > > In my personal experience I have never really felt the need to work with in > records sets in memory for updating data. Usually updating occurs on very > specific records ususally distributed over many tables and all wrapped > within a transaction. > Whenever I needed to update multiple records of table, it was best done by > a corresponding SQL Update statement like e.g. UPDATE employee SET > salary=salary*1.1 WHERE departmentId=123. In this case there is no need to > read the records beforehand and hold them in memory. This can easily be done > using a DBCommand object. > > What exacly someone needs is of course a matter of the underlying problem > and application. And if you really need to have a list of DBRecord objects > it is possible. All I am advising is to review your implementation and > consider alternative approaches. > > But if you feel that things can be improved, then you are welcome to > suggest such an improvement and we will consider it for our next release. > For that most important classes in Empire-db are client allocated so that > they can easily be extended for your own needs. > > Rainer > >
