Representation constraints with GORM

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Representation constraints with GORM

grampajohn
Administrator
I am stuck with major updates to Tariff and TariffSubscription that I cannot commit because grails is crashing when I try to run the tests. The error message is quite obscure, but I suspect it has to do with expecting to be able to write domain objects in groovy, which is not the case. After sifting through a very long (several pages) error message, I believe the core error is this: nested exception is org.hibernate.MappingException: Could not determine type for: org.powertac.common.Tariff, at table: rate, for columns: [org.hibernate.mapping.Column(tariff)] - but I have not yet figured out what it means.

It seems you have to write domain classes in an obscure subset of groovy that's acceptable to GORM. So far, I have not found any clear documentation about what I can and cannot represent in domain types. I have to say, I am quickly losing my enthusiasm for grails if it means we are stuck with GORM.

I want to use lists in a couple places instead of sets. I want to use SortedSets (TreeSets, actually). I want to use a 2-D array. I want to use a list of pairs, without having to define another class just to hold a pair. Maybe I'm just not up to speed on grails, but as far as I can see, none of this is possible. I'm guessing that much of what I've written over the last two weeks is going to have to be re-written. What a pain - and all so we can share data among a small number of services, in a single session, in a single process.

Here's what I would really prefer: domain objects in plain groovy, including messages and events, are serializable. All we really need is to record them when they are created or arrive in the server, to a log file. During a simulation, the database exists ONLY to allow data to be shared among elements of the same server context. After a simulation, it's all going to be dumped. Why are we stuck with relational-friendly representation if we don't need SQL or persistence beyond the scope of a single simulation? It makes no sense.

I suppose at this point we don't have much choice but to press ahead, but I could sure use someone who knows how to build capable representations with GORM, or at least some clear documentation about what's possible and what's not. I'm going to try to figure out how to move my changes to a branch so I can at least commit.
Reply | Threaded
Open this post in threaded view
|

Re: Representation constraints with GORM

grampajohn
Administrator
Sorry about that rant. I was very frustrated. I did manage to work
through the immediate problems and at least get the existing tests to
pass, so it's committed. I suspect there's still a lot of work to do
getting my code compatible with GORM.

John