Is using an ORM like Hibernate recommended in a Gateway module?

Ignition
1

I'm building a Gateway-scoped module with a decent-sized relational domain model, and I'd like to use an ORM like Hibernate rather than hand-writing data access objects over SRConnection. I'd like some clarification on whether that's a recommended approach here in Ignition 8.3. I couldn't find any prior discussion of it on the forum. Thank you!

2

There's no recommendation for or against such. If it helps you maintain correctness, go for it.

3

Thanks a lot Phil for your answer. That's useful to know, and it's the answer I was hoping for rather than a hard no.

I have got a bare-bones bootstrap running, that is, Hibernate ORM 8.0.0.Beta1 against MariaDB 11.8, with SessionFactory built in the Gateway hook. So the basic feasibility question is answered. What I'm less sure about is the design around it, so I'll be happy to get some expert advice.

1. Delegating to DatasourceManager, or not.
Right now Hibernate is using DriverManagerConnectionProvider and opening its own connections, which means the pool is invisible to Ignition (Database Connections). Naturally, it gets none of the platform's failover. The alternative is a custom ConnectionProvider that delegates getConnection() to context.getDatasourceManager().getConnection(name) and closes on release, with hibernate.connection.handling_mode set to release-after-transaction so connections return promptly.

Question: Is SRConnection safe to hand to a framework like this, or does it assume SRConnection being used directly?

2. JDBC driver visibility.
We're currently naming the driver class explicitly.

Question: If we move to a real pool, will DriverManager's ServiceLoader discovery find a driver jar bundled inside the module's ClassLoader, or should we always construct the vendor DataSource directly?

Essentially, I'd like to know if there are any ignition platform expectations I am likely to be quietly breaking? Thanks a lot for your time!

4
  1. SRConnection extends JDBC's Connection, so it is safe to use for any vanilla JDBC purposes. It is necessary to use it to get Ignition's connection setup and pooling, and not using it will seriously break users' expectations for status/performance monitoring. As well as breaking users' expectations for things like secrets management.

I strongly recommend you use a custom ConnectionProvider to bridge Hibernate to Ignition's vanilla connections.

  1. Ignition's JDBC drivers are in isolated classloaders. It is difficult to get access to the actual JDBC driver instances (via reflection on connection pool objects), and may be entirely protected in future Ignition versions. You may be able to declare a module dependency on v8.3's new modularized drivers. If you cannot make Hibernate work without bundling a driver jar in your module, I would drop the idea entirely.
5

Thank you!