64-bit integer support

Vaadin 6 / 7 / 8 Framework UI
1

Hi Vaadin,

Our product has some components extending from Table class and we are planning to add 64-bit integer support to them because our database uses “LONG” to index records. I’m wondering if you guys have any plan or alternative to do so? Or we have to customize the Table class to achieve it?

Thanks,
Han

2

Hi, do you have any specific problem with 64 bit integers? As far as I know Table should support them out of the box.

3

As I mentioned earlier, our database uses “long” for record indices. But Table class seems to use integer as index everywhere, hence we have to convert our long index to int.

For example,

protected Object getIdByIndex(int index);

takes an integer index to get item ID, as well as

protected int indexOfId(Object itemId);

returning an integer index of an item.

Also, Container.Indexed uses integer for indices too.

public Object getIdByIndex(int index);
public List<?> getItemIds(int startIndex, int numberOfItems);
public Object addItemAt(int index) throws UnsupportedOperationException;
public Item addItemAt(int index, Object newItemId) throws UnsupportedOperationException;

are all taking an integer index internally.

We wanted to use “long index” instead of “int index”. And we wonder whether Vaadin has a plan for this, or we have to customize those classes ourselves.

Thanks.

4

Those indexes are into the table. Using a long would imply the Table is designed to hold over 2 billion rows, a questionable requirement for a user interface widget.

You should be able to store your database index LONG into the Table without issue, but the Table’s index probably really should not expect to support over 2 billion records for someone to look at in their browser.

5

I agree that we don’t necessarily need to show over 2b records in browsers. But in our case we could 10b records in total and only record 4b~5b are displayed. Without the support of long index in the table and other related classes, we have to manage the conversion of indices between Vaadin components and our datastore by splitting a long into two integers. The solution is not only incompatible with Vaadin components but also cause trouble tracking the additional integer manually. That’s why we’re trying to find out whether Vaadin has the plan to support it before we start to costomize.

Thanks

6

Oh, I see.

Table itself cannot represent even a million rows at a time due to browser limitations in scrolling. Grid cannot currently either, although there are some plans for supporting “virtual” scrollbars to overcome the browser issues.

That said, supporting Containers with >2bn items might be useful for other reasons. However, to my knowledge a transition to longs is not planned and indeed has not been requested by users until now. It would be a breaking change, perhaps something that could be considered for Vaadin 8. Or, of course, we could add “Container.LongIndexed” or similar.

7

Is there a reason why the Table index has to match your DB record index? That is, we mostly use table indexes for stuff like drag and drop, controlling the insert of a new row at a particular position, and sometimes (with not great success) to ensure a given row is visible. But the index is never related to our ID (which in our case are often UUIDs). You can always get the table row id using your own id (Item id), and if you have a row, if you include your DB record index, you’ll have access to it too, giving you a build-in map between your ID and the table row id.

8

Or just use BeanContainer with bean id as db id:

        container.setBeanIdResolver(new BeanIdResolver<Object, S>() {

            private static final long serialVersionUID = -2931394627816589312L;

            @Override
            public Object getIdForBean(S bean) {
                if (bean instanceof IPK) {
                    return ((IPK)bean).getPK();
                }
                return bean;
            }
            
        });