Crash in ORM reload after model change to specific CFC. Solved by reloading again!

[Brian H.]

Here's a weird one.This started happening to me about midway through
the project. I am using Mach-ii and tied ORMReload() into the code
that reloads the framework when ?reinit is provided in the url. I
don't think M2 is related here but I thought I would mention it.

If I just reload ORM in my browser right now using ?reinit, ORM
reloads and all is good. As soon as I make a change to a specific
entity CFC, even a trivial change like adding a space and saving, it
will crash. If I then reinit again immediately after, it works fine!
The change DOES take effect but I just have to put up with that
initial crash.

I tried a couple other entity CFC and can't reproduce, but EVERY time
that I make any kind of change to InvoiceLine.cfc, this happens after
the first reinit and I have to reinit again.

The two errors I have seen are:


Error while resolving the relationship InvoiceLine in cfc
lib.model.beans.ScheduleBlock. Check the column mapping for this
property.

coldfusion.orm.mapping.CFPropertyBinder$AttributeValidationException:
Error while resolving the relationship InvoiceLine in cfc
lib.model.beans.ScheduleBlock. Check the column mapping for this
property.


-----------


Error while resolving the relationship InvoiceLine in cfc
lib.model.beans.ScheduleBlock. Check the column mapping for this
property.

The error occurred in C:\PROJECTS\.....\httpdocs\Application.cfc: line
110

108 :
109 : <!--- Reload ORM --->
110 : <cfset ORMReload()>
111 : </cffunction>

Same error but for some reason, a different Error Screen
representation.

I have no idea what could be going on here. Some type of cyclical
issue?

FYI, in InvoiceLine.cfc, I have:

<cfproperty name="ScheduleBlocks"
singularname="ScheduleBlock"
fieldtype="one-to-many"
collectiontype="array"
cfc="lib.model.beans.ScheduleBlock"
inverse="true">

And in ScheduleBlock.cfc, I have:

<cfproperty name="InvoiceLine"
fieldtype="many-to-one"
cfc="lib.model.beans.InvoiceLine">

This seems pretty standard to me! Anyone else experience this? Thanks
guys!

-Brian

[Andrew Scott]

People need to understand and I can't stress this enough, the ORM side of
things in ColdFusion is a different kettle of fish. You really should learn
how to use this on its own before diving into using it with ColdBox. Not to
say that you shouldn't but you might get too understand ORM without having
to learn ColdBox as well.

The error message that you are having is because you have your properties
wrong in ColdFusion ORM.

<cfproperty name="InvoiceLine" fieldtype="many-to-one"
cfc="lib.model.beans.InvoiceLine">

Should be

<cfproperty name="InvoiceLine" fieldtype="many-to-one" cfc="

InvoiceLine">

Notice how I have removed the path notation to the CFC?

This is because ORM or hibernate uses the table name to do relationships
with the Entities, that means it has no clue or idea what file system paths
you might have and it doesn't care and will complain as you have just found
out.

Entities are representations of what the table holds and the name of the
table, to do a relationship you use that information in the Database and not
the filename of the Entity. This is one thing that keeps trapping people up
when trying to learn relationships in ORM.

Hope that helps.

Regards,
Andrew Scott
http://www.andyscott.id.au/

[Andrew Scott]

Sorry ignore the ColdBox references, just realised where this was posted.

[Brian H.]

Thanks for the comment Andrew, and I don't want to be argumentative,
but I'm not sure that I agree with your assessment (dotted notation of
CFC path being the culprit) for the following reasons:

1. Upon further reading, you are mostly right that if one set's the
cfclocation property in Application.cfc, <cfset
this.ormsettings.cfclocation = "/lib/model/beans">, then you shouldn't
use anything other then just the CFC name in the cfc="" property. FYI:
The adobe docs state that if this property is NOT set, then it looks
for CFCs at the application root, which SHOULD in theory expect the
dotted notation. I have removed the dotted notation here in both CFCs,
and now I get "Could not find the Coldfusion Component or
Interferface" so I've left them in for now.

2. Every property's CFC reference is named like this with full dotted
notation and the system works perfectly except for this one hickup in
this one CFC. All the other cfproperties with dotted notation work
fine.

3. After the second reinit, the system works fine. You'd think that if
the doted notation was the issue, it would simply fail flat out.

Not trying to say YOU'RE WRONG, but I just don't think that was the
issue here. I could be mistaken however.

-Brian

[Marc Esher]

eh, F it, I'll say it. He's wrong.

I'm talking just about adobe CF, but if yo'ure using the CF property
tag, and you have a related object (manytoone, onetomany) specified in
a CFC attribute, you *need* the full path... unless it's in the same
directory. You might get away with it if you do an import statement in
your cfc, ala:

import com.foo.bah.*;

....

property ... cfc="User"....;

where user is in the com.foo.bah package, but in my experience that's flaky.

I *always* fully-qualify the cfc paths. Always.

> --
> You received this message because you are subscribed to the Google Groups "cf-orm-dev" group.
> To post to this group, send email to cf-or...@googlegroups.com.
> To unsubscribe from this group, send email to cf-orm-dev+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/cf-orm-dev?hl=en.
>
>

[Dan Vega]

That is one of the main reasons I have simplified my layout in my mvc apps...

I have 

+org

  +vega

    +domain

      -BaseEntity

      -User

      -Role

    +Service

      -UserService

etc...

If all of my entities (domain objects) are in one folder I don't have to worry about fully qualifying names. I just didn't like have folders

+ model 

   +user

     -UserService

     -User

   +role

     -RoleService

     -Role

Thank You
Dan Vega
dan...@gmail.com
http://www.danvega.org/

[Matt Quackenbush]

Agreed.  This is my experience as well.

[Andrew Scott]

Brian,

The CFCLocation setting in Application.cfc is there so that people can use
certain directory structures for their CFC's rather than ColdBox scan the
entire directory structure of the web application.

It makes no difference if you use it or not, when coming to the CFC
attribute to the Entity property for relationships.

[Andrew Scott]

Mark,

If you need the full path then explain to me why this works?

property name="Comment" fieldtype="many-to-one" CFC="Post"
fkcolumn="Post" lazy="true";

This is actually in a production website at the moment, it doesn't use the
dot notation so the statement that you NEED is not correct.

I did place the dot notation path and it still worked, so that doesn't
appear to be the problem.

But Marc if you are referencing the Entity to use in your code then you
either have to do an import like you did, or use the full path but again you
don't have to use the full path.

[Marc Esher]

As I said, you don't need the full path if they are in the same
package. Thus is just basic cf stuff... There's nothing ormish here.

Createobject rules apply, basically

Sent from my miniature iPad

On Jun 3, 2011, at 8:51 PM, "Andrew Scott" <and...@andyscott.id.au>
wrote:

[Andrew Scott]

Actually you claimed you *need* and I am telling you that inside the CFC
Entity as an attribute for a relationship you do *NOT NEED*

When referencing the Entity inside code yes you do need, unless inside that
directory. This doesn't apply to the CFC attribute to the property of an
Entity.

Marc, please take into consideration the differences, and what is being
asked as well.

[Andrew Scott]

Brian, is the lib directory a mapping or a directory called lib in the root
of the application?

If it is a mapping I am wondering if that might be the issue, especially
when you removed the path and it works with a different error?

We will probably need to see the relationship of the lib directory to tell
you more. But it is my guess that when you removed the dot notation it was
able to find the Entity, so it seems to make sense.

[Brian H.]

Hey Guys.

@Andrew, "lib" is an application mapping outside of the root
(Application.cfc) of the app.

Based on my understanding, since all of the CFCs are in different
directories, I still need dot notation referencing to let ORM find the
right bean CFCs.

@All, I still don't think that the CFC reference has anything to do
with the problem that I am experiencing here, because as I've
mentioned, all subsequent reloads are fine, and I am NOT getting a
"could not find CFC" error anywhere. It just seems that it has a hard
time evaluating one of the references as soon as the file changes.
After a second reload, it's all peachy.

-Brian

[Brian H.]

@Curt. Correct. Application mapping in Application.cfc. And it is
completely repeatable. I make a change to InvoiceLine.cfc, save,
reload, CRASH. I reload again, and then as many times as I want after,
and it works fine.

-Brian

[Andrew Scott]

I think that if this is how you feel you might be right, I NEVER use the
ormReload() and prefer to change the application name instead to reload
everything. I use a special syntax in development for the Application name
that contains a version.revision.minor type string so it is forced to load
everything from scratch.

I personally did not think that a mapping would be the issue, but just to
clear this up some. Yes you don't *NEED* to use the path to the CFC has a
dot notation path, provided it is in the same directory. If it is outside
then yes you do need the dot notation path as everyone is saying.

But I will also ask another question, is the lib directory also used in the
cfclocation? I am taking a stab in the dark here, but if it is not then it
might not be seen as a persistent entity in this case. I was under the
impression that all persistent entities need to be accessible within one of
two locations the entire webroot structure, or what is defined in the
cfclocation.

[Andrew Scott]

Damn, I forgot to add that there was some discussion that ormReload() is not
also highly reliable. I can't recall what the conversation was about or how
long ago it was, but it might be the same problem you are having here.

Regards,
Andrew Scott
http://www.andyscott.id.au/

> --
> You received this message because you are subscribed to the Google Groups
> "cf-orm-dev" group.
> To post to this group, send email to cf-or...@googlegroups.com.
> To unsubscribe from this group, send email to cf-orm-

> dev+uns...@googlegroups.com.

[Gavin Baumanis]

Hi there,

I, too, have found at times that ormReload() is unreliable.

In fact there was a time where I would;
delete all hbmxml files (because we create the mapping files).
clear the template cache
clear the CFC cache
ormReload()

and it often didn't work for us and so I found that I would often
restart the CF Service to get the expected changes.
I'm pretty sure I had a couple of discussion on here about this exact
issue.

Now - Along the same lines of what Andrew does, we now use;
delete the hbmxml files,
use applicationStop()

and that's it.
We find that the applicationStop() - always ensures that property
changes are reflected in our application.
I no longer use ormReload() at all, ever.

Gavin.

[MaryJoS]

On Sunday, June 5, 2011 6:04:45 AM UTC-4, Gavin Baumanis wrote:

Hi there,

I, too, have found at times that ormReload() is unreliable.

In fact there was a time where I would;
delete all hbmxml files (because we create the mapping files).
clear the template cache
clear the CFC cache
ormReload()

and it often didn't work for us  and so I found that I would often
restart the CF Service to get the expected changes. 

Same experience here, but it depends on the degree of change being done. Having it write out the hibernate files so I could delete them often helps when it's having issues, but sometimes a server restart seems to be the best and easiest way to deal with it, especially in a dev environment, or if I'm not 100% sure there isn't some error in the definitions that it doesn't like.


---  Mary Jo