<https://stackoverflow.com/questions/37104173/grai...
# questions
n
https://stackoverflow.com/questions/37104173/grails-missing-type-or-column-for-columnorder-items-order-item-on-domainrewar I got similar to this error running Grails 2.2.4 Any suggestions please except grails clean (I tried it several times)\
s
I hate to say it, but Grails 2.2.4 is so old, that finding anyone who supports it is probably impossible.
j
Funny you should say that, but I actually have a large 2.2.4 system that I'm continuing to work on. I'm hoping to be able to persuade the clients to pay for the upgrade to Grails 6 (or 7?) at some point but it's difficult to convince them of the benefits, when their actual web application would work just the same as before having spent a whole load of money. I'll have a look at N Subedi's issue in the morning, see if I can help.
s
@John Moore if it's not internet facing, that could be a reason to leave it as is, but if it is internet facing, I'd take a close look at the many CVE's in Grails 2.x But I'm glad to hear that you will see if you can help @N Subedi
g
I’m also guessing it would make more sense to plan to go straight to 7.x at this point, since even in the newest 6.x the dependencies are out of date anyway (though it would certainly be an improvement).
j
I'll start dabbling with the early pre-releases soon.
@N Subedi, you have two different domain classes defined in belongsTo. I have never seen this before and would be surprised if it doesn't cause problems. Try this instead: package rewards class OnlineOrder { Date orderDate Integer orderNumber Float orderTotal static belongsTo = [customer: Customer] static hasMany = [orderItems: OrderItem] static constraints = { } } ----- package rewards class OrderItem { Integer qty Float total static belongsTo = [orders:OnlineOrder] Product product static constraints = { } } That way you remove the ownership ambiguity while still having Product as a property. Also, as an aside and completely unrelated to the issue, what are your reasons for using Float here? I think BigDecimal is the number type which works best in most such situations, although I can't recall the reasons why off the top of my head.
s
Floats
and
Doubles
are not precise, aka they round weirdly. Look at this:
Copy code
groovy> 1F + 1.1F 
 
Result: 2.100000023841858
This is NOT a Groovy error, this is how the JVM works
where as
Copy code
groovy> 1G + 1.1G 
 
Result: 2.1
G
is telling the Groovy compiler to use
BigDecimal
j
@sbglasius, thanks for jogging my memory!
s
A rather important difference especially if working with lots of multiplications šŸ™‚
j
I don't think I have a single Float in any of my Grails apps out there...
s
I a Java application working with
BigDecimal
is tedious, in Groovy it's a breeze, since Groovy has operator overloading
j
Working with Java is tedious!
šŸ‘ 1
(When you're used to Groovy).
n
I am new to this project. We are planning to upgrade to Grails 6. But I need to run this project locally and weird thing is older developers are not getting this issue. grails clean; grails compile works fine, problem is with grails run. Another try we did is copied compiled .classes from working machine to my machine and it's perfectly. Java and Grails versions are same in both machine. @John Moore That is just similar example, we do have such hasMany and belongsTo mapping in many classes, on console some time it shows error for one class and some time another.