Lucee ORM ERROR

[Solida Martin]

I am trying to figure out why ORM is not creating any errors. I have narrowed it down to ormtypes/datatypes but have not figured out how to make it create an error that I can manage in the way I would like.

For example, if a comma gets entered when the ormtype="int" on insert/update it will not error. It will not only ignore the error but goes on acting like everything is fine without inserting/updating any data.

I realize I can prevent the comma issue via validation/regex but the individual example is kinda besides the learning opportunity for me.

[Nando Breiter]

In regards to "learning opportunity", the advantage of using ORM is that it abstracts away relatively mundane database interaction, but at the price of a significant loss of understanding of, and control over, what is going on under the covers, so it is also a disadvantage one has to live with if using ORM.

In my experience, in certain cases it might be considered a good compromise that ORM swallows errors, such as when updating the schema. (There is some difference between the Lucee implementation and the ACF implementation in this regard, and I actually prefer that Lucee swallows some errors.) Otherwise such an error can take the entire application down with it. 

For example, I've been getting an error for over a year now along the lines of "Can't create table t598-3423gls" when updating the schema of an app I've been developing, (it's a temporary table of some sort, and the error message gives no clue as to why Hibernate cannot create it) and I have no idea how to reproduce it in a test case, nor do I get enough information in the debug output to have any clue what is wrong in my configuration, if anything, that I could change. I've spent weeks of time trying to get to the bottom of it. If I create the database fresh with dbcreate="dropcreate", the error disappears. If I import the data of an existing database into a fresh database, it crops up again. It may be related to the extra fields left behind in the database when changes to the schema are made with dbcreate="update" (they are not deleted), but the only way I can keep an application with existing data up is to leave dbcreate="none". Deleting the extraneous fields themselves doesn't help. The weird thing is the schema is updated on an existing database when dbcreate="update", so the error, from my perspective, only takes the application down, uselessly. Of course, there's very likely some good reason this is happening. I simply can't figure out what it is without a significant amount of effort.

In your case, it seems there is code within the ORM implementation along the lines of, in pseudo code

if !(isNumeric(myint)) { myint = null; } 

which sort of makes sense to handle the case where myint is an empty string, which is bound to occur in a web application ... as if the developer decided "Look, I'll do that much conversion for you, the rest you have to handle yourself" and moved on without considering other cases carefully. Without digging deep into the Hibernate codebase (which would defeat the purpose of abstracting all that complexity away), all one can do is speculate, experiment, and then speculate some more.

If ORM errored in this case, you would need to strip any non-numeric characters from strings (HTML has only one datatype, string) passed into an ORM entity property with an integer datatype and then if you were left with an empty string, set the value to null on the ORM entity. So you might as well do that anyway, and make it a habit for all ints and floats (where you must strip all non-numerics except for the decimal point, and if you are left with more than one decimal point, invalidate the field, or deal with a different regional way of delimiting the decimal portion of the number from the whole number portion, like 23'678,56).

If you consider regional number formatting differences, I can understand why number unformatting and validation would be left to the developer. Long story short, the ORM implementation isn't handling the conversion of strings to ints or floats for you. You've still got to do that yourself, and it assumes that every developer knows they have to ensure html strings are properly handled before being persisted. 

Aria Media Sagl
Via Rompada 40
6987 Caslano
Switzerland

+41 (0)91 600 9601
+41 (0)76 303 4477 cell
skype: ariamedia

--
You received this message because you are subscribed to the Google Groups "cf-orm-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cf-orm-dev+...@googlegroups.com.
To post to this group, send email to cf-or...@googlegroups.com.
Visit this group at http://groups.google.com/group/cf-orm-dev.
For more options, visit https://groups.google.com/d/optout.

[Solida Martin]

Thank you for your response. I think for me if this is truly how things work in ORM then I view it as disadvantage.

[Cameron Childress]

On Wed, Aug 26, 2015 at 9:35 AM, Solida Martin wrote:

Thank you for your response. I think for me if this is truly how things work in ORM then I view it as disadvantage.

I tend to look at differences in technology choices as tradeoffs. ORM has a learning curve and there are tradeoffs you may have to put up with but does some wonderful things.

Your milage may vary.

-Cameron

 

--

Cameron Childress
--
p:   678.637.5072

im: cameroncf

facebook | twitter | google+

[Nando Breiter]

On Wed, Aug 26, 2015 at 3:35 PM, Solida Martin <solida...@gmail.com> wrote:

Thank you for your response. I think for me if this is truly how things work in ORM then I view it as disadvantage.

Well, unless you have the capacity and time to dig into the underlying Hibernate implementation, you won't be able to fully understand how things work in ORM. And unless you have the same experience with the codebase as a core Hibernate developer, you probably won't be able to understand why something works the way it does: if it's a bug, it's intentional, if it's a good idea, a compromise because of some x, etc ...

So sometimes, that's a disadvantage. But as Cameron says, it's all about tradeoffs. If you'd rather write all the SQL, you'll have full knowledge and transparency what is going on when something is persisted, but then you'll have to write and maintain that code, and find and fix the bugs you introduce into it. To be fair, I like typing EntitySave( complexThing ); and being done with it. It is really nice - except when it doesn't work and you have to dig like a rat to figure out why.

For myself, I'm leaning toward the opinion that where long-term reliability is important, depending on CF ORM probably isn't a good choice. It doesn't seem clear at this point if the Lucee ORM extension will be well maintained (although I think putting it in an extension is a very good idea to ensure maintainability). And I'm also influenced by the current trend toward functional programming ... maybe CF had the right idea in the very beginning, stick "an entity" in a struct, validate it, and then pass the struct to your SQL code to persist it. Clean and simple without all the unnecessary noise that OO introduces. 

But now my brain is so wired into the OO concept, I feel "naked" without it, as if data ALWAYS has to be fenced within a container of some sort.