Develop Reference

JavaFx TableView CRUD for large database tables

I'm looking for sample apps or documentation for displaying a large table in JavaFx TableView , without loading the entire table into memory beforehand. CRUD capabilities would be nice, too, though I can write this myself if necessary.
All the examples I have found pre-load data into a an observable list (in memory, I assume), which I can't do for, say, 5 million records!
I have worked in Java Swing with table models that get their data from JDBC ResultSets, is there something similar I can do for JavaFx TableView? I also added my own sort and column layout persistence in Swing, and am looking to do something similar in JavaFx.
This may be a "beginner" question, or it's possible that I missed something simple while scouring through the JavaFx info.

Each TableView must has a model class. you can easily set your model class to table view.
For example you have class Student with (id,name,avg)
define an ObservableList of Student just like
ObservableList<Student> stdList = FXCollections.observableArrayList();
then set the list to the table view by
tableView.setDate(stdList);
and Now you can do anything you imagine (CRUD) on the list.

How to accomplish CRUD operations on dynamic forms?

I have followed Balusc's 1st method to create dynamic form from fields defined in database.
I can get field names and values of posted fields.
But I am confused about how to save values into database.
Should I precreate a table to hold values after creating form and
save values there manually (by forming SQL query manually)?
Should I convert name/value pairs to JSON objects
and save?
Should I create a simple table with id,name,value field and
save name/value pairs here (Like EAV Scheme)?
Or is there any way for persisting posted values into database?
Regards

It look like that you're trying to work bottom-up instead of top-down.
The dynamic form in the linked answer is intented to be reused among all existing tables without the need to manually create separate JSF CRUD forms on "hardcoded" Facelets files for every single table. You should already have a generic model available which contains information about all available columns in the particular DB table (which is Field in the linked answer). This information can be extracted dynamically and generically via JPA metadata information (how to do that in turn depends on the JPA provider used) or just via good 'ol JDBC ResultSetMetaData class once during application's startup.
If you really need to work bottom-up, then it gets trickier. Creating tables/columns during runtime is namely a very bad design (unless you intend to develop some kind of DB management tool like PhpMyAdmin or so, of course). Without the need to create tables/columns runtime, you should basically have 3 tables:
1 table which contains information about which "virtual" DB tables are all available.
1 table which contains information which columns one such "virtual" DB table has.
1 table which contains information which values one such column has.
Then you should link them together by FK relationships.

How do I make the data passed in a table is no longer displayed in the other

I have a problem for a couple of hours does not resolve, is the following.
I have a Table A and Table B.
Table A is filled with a ResultSet, and Table B is being added to products available in Table A
What I am trying to achieve is: Once you click on the Add button Spend the product of Table A to Table B, and the last product is no longer displayed in Table A.

The responsibility to inform the tables that data was added and remove to and from them is completely up to you, and should be handled in each table's model. If you want to 'move' data from one to the other, you need to remove that data from the model of the first table and add it to the 2nd. Once that is done, both models need to be informed of the change via fireTableDataChanged, so they know to redraw.

I would endorse #Colby's and #GETah's suggestion to focus on the model. Also consider giving modelA and modelB access to a common data structure, say List<Product>, where each Product has a boolean attribute that allows each model to to decide what it's corresponding view can see.

Get and remove the selected element from tableA's TableModel and add it to the tableB's TableModel and then refresh both tables.
See this tutorial on using JTable and TableModel

How set a table row's attribute class dynamically with clojure/enlive?

I have created a table using enlive template engine. what I have done, is create a singe table row and repeated that row up to the no of row needed dynamically. But, I have some problems update the each row's attribute class.
How can I set the class attribute for every table row dynamically, say even odd manner?

There is a thread on the enlive mailing list where Christophe Grand explains how to do this.
I also share the feeling that if you can use nth-child selector it is way cleaner.

How to retrieve "${selectedElement}" from a JTable where the elements are bound to a List

In my application I have a JTable and a List.
The List:
The list is populated using a JPA query. The user can re-execute the query by changing attributes in the GUI. Let's assume the query has a named parameter "year" and the user can change this. Then the following happens (simplified by leaving out exception handling):
myList.clear()
mylist.addAll( myQuery.setParameter("year", 2010) )
As the list changes, the binding fires the required handlers and the table now reflects the new dataset.
The JTable:
The contents of the JTable come from a BeansBinding (more precisely a JTableBinding). The binding source is the aforementioned list.
The query is only executed for intensive tasks. Like applying a rough filter on a huge dataset. The earlier example with the year is a good example. This will always return a manageable chunk of data to the client. Now, to have a more responsive user experience, more fine-grained filters happen in the JTable itself. This avoids unnecessary round-trips to the database.
Next, assume the following scenario: A user selects a row in the table and hit's the delete button. If the table has not been filtered the required code is straightforward (again, no error-checking, concurrency locking, and exception handlers for code simplicity):
MyObject = myList.get( myTable.getSelectedRow() );
myEntityManager.getTransaction().begin()
myEntityManager.remove( myObject )
myEntityManager.getTransaction().commit()
However: If the table is filtered on the client side, the table won't reflect the data inside the List. So getSelectedRow() will not return an index which will map to the same entry in the List (I have not tested this, but I beleive I am correct with this assumption?)
So... My question:
How best to solve this?
A possible solution?
I've solved the problem at hand with the following:
I created a new Bean called selectedTableElement which contains a member holding the element which is currently selected in the table.
Next, I created a new binding (source: my table, target: my "selectedElement" bean) using
binding = Bindings.createAutoBinding(UpdateStrategy.READ_WRITE, myTable, ELProperty.create("${selectedElement}"), selectedTableElement, BeanProperty.create("selectedElement"), "selectedElementBinding");
This solution effectively solves the problem by keeping track of the selected element of the table using Beans Binding.
But is this really necessary? It feels clunky to me. A whole new class only the encapsulate the selected element? Is there no other, more direct way of retrieving the "${selectedElement}" property of the JTable?

I'll try to answer to both your questions.
Regarding the first question (the filtered selected index vs the real list index):
I assume that you bound the table using BeansBinding, via createJTableBinding. So, the client-side filtering might be applied through the use of swing TableRowSorter and RowFilter. Am I right ? if so, you could use the method
int row = myTable.convertRowIndexToModel(myTable.getSelectedRow());
to convert the selected row in the filtered view to the actual selected row in the model.
For the second question (bean to keep the selected item of table)
You could also create a binding using this as the source/target object, and create a property selectedElement in the class containing the table. Thus, you won't need another class. The code will be : createAutoBinding(UpdateStrategy.READ_WRITE, myTable,
ELProperty.create("${selectedElement}"), this, BeanProperty.create("selectedElement"), "selectedElementBinding");
(note also that READ_WRITE binding is not really used, as beans binding does not support changing the selected element from the bound property)