Hrorm Forums

New Release 0.10.0

#21

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

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

#22

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 {
				q.put(e);
				return q;
			} catch (InterruptedException e1) {
				throw new RuntimeException(e1);
			}
		}, where);
		done[0] = true;
	});

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

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

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ā€ (https://docs.oracle.com/javase/7/docs/api/javax/sql/DataSource.html 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()) {
		connectionConsumer.accept(connection);
	} catch (SQLException e) {
		throw new HrormException(e);
	}
}

Switching to DataStore enables connection pooling support with C3P0 (http://www.mchange.com/projects/c3p0/index.html) and DBCP (http://commons.apache.org/dbcp/)

Edit 3:
Oooh, look at this!
https://docs.oracle.com/javase/8/docs/api/java/sql/JDBCType.html

#24

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.

#25

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?

#26

I donā€™t see why not either.