This makes me a uneasy. I’d suggest that the point of code execution is too late to be installing required libraries and that this should be discouraged. If it were implemented with a feature switch, I’d prefer to see the default behaviour have the feature turned off.

Instead, I’d prefer to see published methods for prebuilding Lucee with the dependencies that your application requires. Also, for an error to be thrown when libraries are missing who’s message points at instructions for installing the extension either manually or through some build process.

Same, and for the same reasons. It’s debatable whether this is a feature that should be a run time possibility at all IMO, but it def should not be the default behaviour. And even the usage of it should come with heavy caveats that it’s not the right way to go about things.

by default this extensions are bundled with Lucee and installed on a fresh install or an update from 4.5. This is the case for all features that have been moved to an extension and was part of the core in 4.5.

So this functionality only is used when the extension was uninstalled before.

If Lucee fails to install the extension it still throws an exception like this:

return new ApplicationException("No ORM Engine installed!","Check out the Extension Store in the Lucee Administrator for \"ORM\".");

What we kind of have, Lucee 5 defines the “require-extension” in the manifest file of the core, so we can define what extension we like to see installed by default , “require” is maybe the wrong word then you can still uninstall on a later state. We will change that to something like “initial-extension” in the future and as soon we move required stuff to extension we will use again “require-extensions”. (In th future the Lucee core will only be an extension as well, already today there is no big difference between extensions and core)

in general you are right, but not in that case then lucee has always an ORM engine running, if no ORM engine is installed, Lucee is using the “DummyORMEngine”, this “ORM Engine” does nothing else than complain that no ORM Engine is installed, so the point is in Lucee the function “entityNew” is hardwired to ORM always, the only thing that can change is the ORM Engine used.

So installing the hibernate extension does not mean that we add the function “entityNew”, it means that we add a different engine behind it. Otherwise this hole ticket would be useless, then without having the extension installed, Lucee would have no clue what “entityNew” is and what it has to do.

lucee has always an ORM engine running, if no ORM engine is installed, Lucee is using the “DummyORMEngine”, this “ORM Engine” does nothing else than complain that no ORM Engine is installed, so the point is in Lucee the function “entityNew” is hardwired to ORM always, the only thing that can change is the ORM Engine used.So installing the hibernate extension does not mean that we add the function “entityNew”, it means that we add a different engine behind it.

Is that really a very good approach? What’s the real-world benefit of the hardwiring the functions in the language, but leaving them non-functional?

It’s quite unusual for a module’s API to be present, even when the module itself is not.

I can understand the interface to an ORM system being fixed: defining how the module’s method signatures need to be implemented and the like, but it’s very odd to leave implementation vestiges of it in the language when the implementation is not present.You could (and probably will) argue that there is an implementation present in this “DummyOrmEngine” thing but… why would you do that? Other than to solve the problem you’ve built for yourself by leaving the functions themselves in the language.

How did the decision to do it that way get arrived at? Was this something the TAG decided?

this decision predates Tag, this even predates Lucee itself, this decision was made when we started the Hibernate implementation with Railo (more later).

ORM (not Hibernate) has a very deep integration into the core, as you maybe know you define your ORM objects with components, so a lot of the ORM logic is in the core. Move all this logic to an extension is nearly impossible and would make the code a lot more complicated. In addition it would make no sense as soon you have more than one ORM extension (what is planned) because you would end with a lot of redundant code.

Lucee is aware of ORM, but not of Hibernate, you can compare this with datasources. Lucee is aware of JDBC, but not of MySQL, the complete logic of query objects, the query tags, connection pooling … is in the Lucee core, but everything that is specific to a specific implementation like MySQL is in the JDBC driver itself, that makes the JDBC driver a lot easier to implement. We have exactly the same for ORM as well, all the stuff that is specific for Hibernate is in the extension the rest is in the Lucee core.

This is not new to Lucee 5, we had this separation between hibernate and ORM in general from beginning, then we planned to be open in the future for alternative ORM engines. In fact you can define a different ORM engine in your lucee-server.xml in Lucee 4.5 if you like.

Lucee is aware of ORM, but not of Hibernate, you can compare this with datasources.Lucee is aware of JDBC, but not of MySQL, the complete logic of query objects, the query tags, connection pooling … is in the Lucee core

Actually framed like that it makes sense, especially from the perspective of how other stuff in CFML has been implemented, as you point out.