Fork me on GitHub

First cut of documentation for middleware: -- feedback and suggestions welcome!


I suspect most people will be more excited about a way to provide default options ūüôā but I think I know at least one person here who might be excited about the logging aspects of middleware!


I'd appreciate at least some folks actually walking through that documentation and making sure that the examples really work for them.

ūüĎć 1

Also, TIL: timestamp in SQL Server is not like other databases -- it's a monotonically increasing numeric type that you cannot insert values into! So my tests have to use datetime for MS SQL and timestamp for everything else. Good job SQL is standardized, eh?


have you considered using interceptors in place of the middleware pattern?


@U08E8UGF7 because of the way next.jdbc was designed and optimized for performance, neither a strict middleware approach nor a strict interceptor approach would work. If you look at what I've implemented, you'll see it's really part middleware and part interceptor: it wraps the connectable and the builder like middleware in order to provide four interception points (pre/post/row/resultset).


@U04V70XH6 understood, thanks for the insight.


does next.jdbc has ddl support like java.jdbc?


@U0NBGRGD6 no, but the DDL support in c.j.j. was very minimal -- just helpers to construct create/delete DDL strings. It wasn't worth adding those to next.jdbc.


You can execute any DDL with next.jdbc, it just doesn't help you create those strings.