Async Execution of SQL about sql2o HOT 6 CLOSED

@sachinwalia2k8 thanks for posting the DbUtils link, that's very helpful. It seems like this would live in sql2o as an extension of the Query class, something like AsyncQuery. We'll look into it.

from sql2o.

@aldenquimby, I was thinking along the same line. Basically AsyncQuery could extend Query class. All the execute methods in such a case would return java.util.concurrent.Future object or Guava com.google.common.util.concurrent.ListenableFuture as it supports callbacks as well.

from sql2o.

i put up a few ideas on a branch for @aaberg to consider. I think an AsyncExecutor class would be the best idea, because it's a little clunky to extend Query directly. The usage would be:

Future<User> futureUser = sql2o.createQuery("SELECT * FROM user WHERE name = :name")
                               .addParameter("name", name)
                               .async()
                               .executeAndFetchFirst(User.class);

Unless someone objects to adding this, I'll update the async interface after feedback and add tests to make sure things work as expected.

from sql2o.

This would certainly be a cool addition to the api. At the same time, it might cause all kinds of interesting thread-safety issues. Consider the following:

sql2o.withConnection((Connection con, Object param) -> {
    Query q = connection.createQuery("insert into someTable(id, val) values (:id, :val);

    Long key1 = q.addParameter("val", val1).addParameter("id",  someId).async().executeUpdate().getKey(Long.class);
    Long key2 = q.addParameter("val", val1).addParameter("id",  someId).async().executeUpdate().getKey(Long.class);
});

In the above example we can't guarantee that key1 and key2 variables actually will hold the right values. They might be switched, or both key1 and key2 may get the same value.
To work it would require all instances of Connection and Query classes to be thread safe, which they aren't today.

I think we should wait to see how the overall architecture of sql2o v. 2.0 will look like, and then reconsider this feature.

from sql2o.

Ok so should we close this issue because we won't be implementing it in the foreseeable future? Do we have a place for backlogged issues? Maybe we could add a Backlog list to the Trello board and make it public?

from sql2o.

I think it is a very good idea to make the board public and put stuff like this in a backlog there.

I'll mark it as wontfix and close it for now.

For reference. The board is here:
https://trello.com/b/8dgYmypY/sql2o

from sql2o.