cfml

Has anyone seen an issue where ormreload() doesn’t do anything?  I have an app running on Lucee 5.3.8.206 and in local dev ormreload is ran on every request.  However, any changes to the orm cfcs are not picked up when dbcreate is set to update.  If I change it dropcreate the tables are rebuilt.  Anyone have any ideas?  TIA.

Its probably not that changes are not picked up, but that one of the cfcs is failing to update the database, and the rest are being aborted. I have run into this issue where a table or field cannot be created for some reason. Setup logging on the database to see the errors

Then when you dropcreate, it appears to be working but thats just because whatever was causing the issue is no longer applying

You are correct.  It is failing as it is trying to create columns in the db that already exist.  Not sure how to get past that.

What database engine? I believe I had this issue once with casing, say table name in entity was "Contact" but database only supported "contact", and so it constantly tried to add this

It looks like it is happening on columns added to tables that were added outside of the ORM cfcs

So it could be conflicting field name casing, index or foreignkeys. I would look at the actual error generated in the mysql error log and try to find out what the manually added field is missing

So I went as far as to just drop all the tables and have orm rebuild them.  That it did just fine without error.  However, on the very next request I get the following  error….

Error during DDL export;Error during DDL export;org.hibernate.JDBCException:

Caused by: java.sql.SQLSyntaxErrorException: Duplicate column name ‘sytemenable’

For some reason orm is trying add columns that exist that it just created.

Ok so it has been a while since I have been deep in orm session mumbo jumbo, for context this is adobe 2018. I would like some confirmation to make sure my memory is not causing me to have issues. But if I am using 2 datasources in my system. 1 that uses ORM and 1 that doesn't. If I have some objects being loaded in via orm with datasource 1, and then I run a transaction against datasource 2, does that close the session in datasource 1? Going to explain the code in the thread for more detail.

This is in FW/1.
In our before we entityNew(logObject) and populate that log object, we don't save it. We also load some information about the user credentials/token that called the API using ORM. We then run a direct non orm query against datasource 1. Afterwards we create a transaction against datasource 2, run a few queries converting/transfering data, and then close the transaction. We then use ORM to load a defined object that we use to determine the returned statuscode etc. When we try to load this object we are getting a `Session/EntityManager is closed` error.

This isn't happening to me locally, still trying to investigate why. But anyone know if this should be a possible flow. We are doing very little with ORM. It has been ripped out in 80% of the code so far and really only is used for token authorization and users roles/right checks at this point around our code.

Additional information. This is working just fine with an API designed the exact same way. So something else is causing the EntityManager to close......... but WHYYYYY

What is this.ormSettings.automanageSession set to?

"In our before we entityNew(logObject) and populate that log object, we don't save it. We also load some information about the user credentials/token that called the API using ORM. We then run a direct non orm query against datasource 1" - You mean you load an object from datasource 1 and then run a SQL query (with cf query) using that datasource?

Yes to your second question, looking to answer your first.

And to explain to your second question we have all but abandoned orm in our actual controller and business code. There are just a few places surrounding our controllers in the request lifecycle which are using it and are planned to be converted in the future (aka when there is no other work and qa has proper time to do full regression testing once we have that in place) using it but haven't done so yet. I just haven't run into this issue before with the entity manager getting closed on me.

Gotcha. So yeah you basically can't issue a cfquery using the datasource that was used when opening the ormsession. There are two ways to solve this, use the session manager to create a native SQL query, or create a separate datasource for the SQL queries.

The hibernate native SQL query is not as ergonomic as cfquery, and so I have a separate datasource I use just to issue SQL against the same database as the orm

However, you cannot use two different datasources from the same transaction

Your term "cannot" is false because we do in every other location. The new part of this code is adding in a second datasource and running a query there.

And there is not transaction over the first datasource

Also in a separate api call that does exactly the same thing, it is working.

Starts with orm call on ds1
Makes basic query call on ds1
Opens transaction on ds2
runs basic queries on ds2
Closes transaction on ds2
Runs Orm calls on ds1

Well by "cannot" I don't necessarily means "doesn't run" - I mean, "should not" or "makes no sense"

This is because of the way that Hibernate/cfquery manage transactions

Try this:
Starts with orm call on ds1
Makes basic query call on ds2

That's my advice from my experience. I can't explain why or what's happening under the scene or why it works for you in one place and not another

Unfortunately that isn't a very feasible test as I have to tear a lot out for that to test. If I get a few minutes I will try it.

Gotcha. Perhaps then create a ds3 (which is exactly the same as ds1) and replace the offending cfquery datasource with ds3. Therefore nothing to tear out and be quicker to test and confirm if the problem is between the datasources or not

The issue could also be here, this sounds familiar problem to me:
Closes transaction on ds2
Runs Orm calls on ds1

Its not clear the way the transaction/session manager works under the hood. So I tend to keep my ORM/SQL work completely separate. I know I have run into issues where I need to do work in ORM, then work in SQL, then follow up with work in ORM. In these cases, I:
• Do ORM work in a transaction, afterwards call ormCloseSession()
• Do my SQL work
• Do ORM work in new transaction

Was able to confirm with the same code and same cf version it appears that after the transaction the ORM session is not being reopened or recreated (not sure underneath which is does) on one server but is being reopened  on my local server. Anyone have any idea if there is an admin setting that may control this? We are using same application.cfc

```  &lt;/cftransaction&gt;
            &lt;cfset var ses = ORMGetSession() /&gt;
            &lt;cfdump var="#ses#" abort="false"/&gt;
            &lt;cfdump var="#ses.isOpen()#" abort="true"/&gt;
        &lt;cfcatch&gt;
        &lt;cfdump var="#cfcatch#" abort="true" /&gt;
            &lt;cfset arrayAppend(errors,cfcatch) /&gt;
        &lt;/cfcatch&gt;
        &lt;/cftry&gt;```
Exact code block used to confirm to get 2 seperate answers to the ses.isOpen() call.

Here you go Tom! I'll perfect this later, but it gives you a quick preview of the theming capabilities! I created both the theme and post with the theme attached in a matter of 20 minutes (mainly selecting the images)
<https://www.gregoryalexander.com/blog/2022/6/21/Joshua-Tree-Scenic-Drive>

Any other theme and scenic drive suggestions?:)

Is there a good article on how to covert ACF ORM to Lucee? I want to port Galaxie Blog over to Lucee and am not quite sure where to begin.

When I moved from ACF9 to Railo/Lucee some years ago I did encounter <https://blog.simplicityweb.co.uk/93/migrating-from-coldfusion-to-railo-part-6-more-orm-issues|a few issues> but I think most have been sorted since. If you do find any you can bring them up here.

You might wait until Lucee 6 for this as they've upgraded Hibernate from (I think) v3 to v5. I wouldn't recommend dealing with the differences between ACF ORM and Lucee ORM right now. There are not tons of them but there are some.

Unless you wanted to drop Hibernate completely and move to something like Quick, but that's more of an undertaking

Thanks for the feedback all, when is Lucee 6 coming out to the best of your knowlege? I have a ton of code with ACF Orm.

They haven't announced a release schedule to my knowledge but they've been talking about it a lot more lately and I know they're wrapping up the 5.x branch. So I wouldn't invest any time doing a conversion to support Hibernate 3 if I were you, although it's conceivable that the delta between what you'd have to do for v3 vs. v5 is not huge. Mostly the bugs in v3 are a bother if you mix and match HQL with SQL but if you don't do that, it may be OK to get started

The updated Hibernate v5 extension will work with Lucee 5.3.10, however there are some bugs we are still tracking for it to to have drop in compatibility.  Two are regressions and three are issues of compatibility.

<https://luceeserver.atlassian.net/browse/LDEV-4150> - not a regression, occurs in both 3.5 and 5.4

<https://luceeserver.atlassian.net/browse/LDEV-4121> - not a regression, , occurs in both 3.5 and 5.4

<https://luceeserver.atlassian.net/browse/LDEV-4067> - not a regression, , occurs in both 3.5 and 5.4

<https://luceeserver.atlassian.net/browse/LDEV-3641> - :bomb: 5.4 regression, only occurs in 5.4 :bomb:

<https://luceeserver.atlassian.net/browse/LDEV-4276> - :bomb: 5.4 regression, only occurs in 5.4 :bomb:
(edited)

This one, however, is a total blocker for most using ORM and is a bug in the current version of Lucee: <https://luceeserver.atlassian.net/jira/software/c/projects/LDEV/issues/LDEV-4017>

cc/ <@U070SQMD1>

The last link that you provided does not work JClausen. Can you please provide another link?

Looks like that one only works in Desktop.  Here you go:  <https://luceeserver.atlassian.net/browse/LDEV-4017>

Thanks! Yea, that is not good, hopefully they will fix it soon!

<@UHCG76PEJ> In AFC  ORM, relationships are defined using the "hasMany" and "belongsTo" methods. In Lucee ORM, relationships are defined using the "property" and "ormSettings" methods.  Its not ultra-direct but very close. I would rope in Zackster into this as if anyone understands Lucee ORM, it would be him.

I am running into a weird issue and I am hoping someone has an idea as to what is going on.   I am working on a project using a Lucee and a postgres database .  In the orm cfcs all of the ID columns are set to use a generator of sequence and each one is assigned to use a specific sequence.

In development this works great.  However, in production it doesn't work.  In production the declared sequence is ignored and all tables are using a sequence of "hibernate_sequence"

Anyone have any idea as to what would be causing this?

Wait.  What do you have for your generator= parameter in your ORM Bean?

If you are trying to have the DB select the next ID in the sequence rather than your ORM engine, you should be using "native".  All the other types will do different trickery on the ORM Engine side to determine the next ID available.

sequence, for example, does a select statement to determine the max value, and adds 1.  Which for certain DB types (like Oracle), isn't valid or optimized (but is pretty much required for flat-file DBs)