Best way to keep track of record in JTable

[Ixus See]

Hello~~

May I know what is the best way to keep track of records in JTable?

Lets say I want to add, delete, update, a record from JTable.

I know I have to use the Table model but I don't know a good way to track the record so that when I remove row 3, the element at a collection will be remove too

[Roel De Nijs]

I used JTable.getSelectedRow() to get the index of the selected row and then I invoked a method on my custom TableModel which returns a room based on the index of the selected row.

[Roberto Perillo]

Same here.

[Ixus See]

Roberto Perillo wrote:Same here.

okie imagine if you populate the table with 10 records and in the model you use vector to keep track of the records

you delete record 5, therefore record 5 in vector will also be deleted.

then you get record 7, you will most likely be getting record 6.

how do you prevent this?

[Darryl Burke]

Ixus See wrote:you delete record 5, therefore record 5 in vector will also be deleted.

then you get record 7, you will most likely be getting record 6.

No, you'll be getting record 8.

Ixus See wrote:how do you prevent this?

For multiple deletions in a single pass, start with the highest index.

Don't forget to use modelToView / viewToModel if your table can be sorted.

[Roel De Nijs]

Why would you use a Vector A simple List will do the job too (and be more performant)

In my application my TableModel is refreshed after each modification (only bookings) by executing the search again with the last known search criteria. So a deleted record will not mess up the indexes.

[Ixus See]

Because Vector is ordered. I am not sure about Arraylist =x

[Roel De Nijs]

If you are not sure about ArrayList, did you check its javadoc?

[Oladeji Oluwasayo]

For the sake of ease, instead feeding your GUI with a Vector or List from the database, let your database spit out a Map of record numbers and their records (if you want arrangement use a TreeMap else use HashMap). For security reasons, do not be tempted to just spit out your database cache to the GUI (you don't wanna live with the aftermath). Okay. so you make a copy of you cache (if you implemented one). You should have something like this in the database.

public Map getInventory() {
   //do any locking you want
   return new HashMap(cache);

   //DO NOT BE TEMPTED TO DO SOMETHING LIKE THIS
   //return cache;

   //DO NOT ALSO BE TEMPTED TO DO SOMETHING LIKE THIS
   //Map map = cache;
   //return map;

Don't ever let your display relate too much with the data from the database. Let the Controller fetch this Map from the database, use it to construct another Model update the model reference in the main GUI class (very important) and apply the new model on the JTable. This way, the View just sees new models and displays them, nothing more. The model will hold the record numbers in the first column and the other data in the rest according to your schema.
If you want to manipulate a record, call getSelectedRow() on the JTable then call getValueAt(selectedRow, 0), cast the result back to int (from most likely, Integer). You now know which record to manipulate. You can use a switch statement to implement your getValueAt() method in the model.
You should have something like this.

int row = table.getSelectedRow();
//test if row == -1 in which case the user has not made any selection; show a dialog to this effect or 
//paste a flashing message in your status panel to alert the user of this.
int recNo = (int) model.getValueAt(row, 0);
//manipulate the record corresponding to recNo

Sorted data structures usually come with a performance hit and with this strategy, you do not need a sorted data structure behind the model to get the right record number from your JTable. The only downside of the unsorted data structure used here is that the user sees records that are not arranged (which should not be too annoying I guess). Just document your choice in your choices.txt.
And please, don't ever forget to update the main GUI class' reference to the table model in every search/refresh/record manipulation. Else you end up modifying record 4 instead of record maybe 15 after performing a search that returns maybe 5 records. You get a feel of the headache that can cause, right?
I can't upload complete working code but I think this should help. I'm still waiting for my result. Hoping for the best.