Hrorm Forums

New Release 0.10.0


Also, you have not been obnoxious at all. Just giving your opinion about how things should work in a fair and productive way.

At, we welcome criticism. All one of us. :wink:


I’ll try and update it to 0.10.2 tonight and link it here… it was a rather trivial add IIRC.

We’re all adults here, again I’m admitting I’ve been obnoxious about it.

And don’t feel too sorry for me now- I can probably wrap around foldingSelect to get an entity Stream with some magic Consumer like a BlockingQueue and make that into a utility method somewhere- since I’m working in multi-threaded environments anyway.

Update: I wrote this out of curiosity for how a BlockingQueue solution would work. For a first pass it isn’t entirely awful.

public <E> Stream<E> foldingStream(KeylessDao<E> dao, Where where) {
        // I'd use the container's ManagedExecutorService here.
	Executor single = Executors.newSingleThreadExecutor(); 
	final boolean[] done = { false };
	final BlockingQueue<E> queue =new LinkedBlockingQueue<>(1);
	((ExecutorService) single).submit(() -> {
		dao.foldingSelect(queue, (q, e) -> {
			try {
				return q;
			} catch (InterruptedException e1) {
				throw new RuntimeException(e1);
		}, where);
		done[0] = true;

			Spliterators.spliteratorUnknownSize(new Iterator<E>() {
				public boolean hasNext() {
					return !queue.isEmpty() || !done[0];

				public E next() {
					try {
						return queue.take();
					} catch (InterruptedException e) {
						throw new RuntimeException(e);
			}, Spliterator.ORDERED)
	, false);


Also I think this is something we could address, and I was reminded of it by one of your previous arguments vs Streams- what do we do in the case of connection pooling, etc.

It might be a good idea to take a connection “Supplier” ( looks like the winner actually) rather than a connection, and it might be a good idea to manage and watch the connection inside of HRORM itself. Then any code that utilizes a connection would have to call something like:

public void getConnection(Consumer<Connection> connectionConsumer) {
	DataSource dataSource = getDatasource();
        // Any retries / fault tolerances would have to go here.
        // Try -> Fail -> Rollback TX -> Try again
	try (Connection connection = dataSource.getConnection()) {
	} catch (SQLException e) {
		throw new HrormException(e);

Switching to DataStore enables connection pooling support with C3P0 ( and DBCP (

Edit 3:
Oooh, look at this!


Your solution looks much cleaner than mine.

But really, I think both of these lead me to think it’s pretty hard to do it outside of hrorm itself.


Regarding the DataSource or Supplier<Connection> have you taken a look at the Transactor class? It somewhat does what you are talking about. Extending it to use a DataSource should be quite simple.

Also, I do not think this is an either/or question. Why not have the DaoBuilder objects construct a Dao from all of the above?


I don’t see why not either.