ORMs and Immutability

[Carl Jokl]

While in the process of creating some basic classes relating do domain
objects a problem occurred to me. I know that immutability is quite in
vogue at the moment due to its ability to use objects with concurrency
without needing locks. Some of the domain objects I was looking at
implementing looked like the kind of thing that could be implemented
as immutable. However immutable domain classes strike me as not
working well or at all with ORM. ORM usually mandates objects with a
zero argument constructor and have all the important state available
through get/set pairs or at least internal fields inside the class
that can be set from the database. An immutable class is really like
the other extreme. It would put all the creation state in the
constructor because it cannot be changed later. For completeness the
internal fields can also be declared final just to make it more
obvious if anything would actually change state. I don't see this as
something that would be compatible with automatic ORM. It can still be
done manually with JDBC. I just wondered if anyone else has considered
this same problem and has any thought or insights.

I ended up having two implementations for each domain object or domain
object component. One implementation was immutable and the other was
mutable. Also I made a method that could be called to convert a
mutable object to an immutable version. This would mean in theory that
there is a mutable version which plays nicely with ORM and an
immutable version which plays nicely with multi threaded contexts.
This means though that each domain or domain component needs three
source files, a common interface or abstract base class, an immutable
implementation and a mutable implementation. This starts to feel like
possibly more work that in should be (I wonder if this would get into
the topic of other platforms that might be able to declare objects as
immutable explicitly in the language avoiding this extra work of doing
it by hand).

It is useful to sanity check my observations.

[Graham Allan]

That kind of arrangement sounds familiar to me. The mutable versions are used for write operations (e.g. the user changing data through a web page), the immutable versions for read-only operations (e.g. performing calculations, generating reports etc). In my scenario I have the added problem that the mutable versions are by far the more common throughout the codebase, and  I use a mutable->immutable converter for trying to wean bits of the code off the mutable versions when they don't need them. It sounds like you're in a better position, where you can make the choice of immutable/mutable to begin with.

If you want to have data changing in-place in your database, rather than a "clone with modifications and deactivate the old" model and you want to use the mutable versions in your code, then I don't see a way around having the different classes. Another approach would be to only deal with the immutable versions in your domain logic, and use something like the repository pattern to modify the mutable object when you want to persist it.

I don't know if Hibernate is your ORM framework, but it has a feature I found handy for fetching immutable objects, the "select new" syntax.

A tangential point, but there's other (better?) reasons to have immutable objects than just being thread safe, and that is how much easier it is to reason about them. 

And finally, on a shamelessly self-promoting (some may say 'shilling') note, if you want a way to automatically check your classes are/remain immutable, check out my project here: http://code.google.com/p/mutability-detector/

Kind regards,

Graham Allan

[Carl Jokl]

Was that the project that was mentioned in a lighting talk at the London JUG by any chance or a different one?

I could see a benefit for immutable object for those that live in a Servlet container session cache especially if the web container could be clustered and everything in the Session needs to be replicated across servers. The mutable versions would play nicely with an ORM.

At this point I am not using any ORM and there are no domain objects at all in the system apart from some demonstration ones I created. I have been demoing with plain JDBC population (which is tedious) but it avoid having to add a dependency on the persistence API at this stage (though the mutable objects are ripe for modification in the future to add ORM annotations to them. 

At this point the work I have done may not go anywhere as the use of domain objects has not been well received so far. 

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

[Graham Allan]

On 21 December 2011 14:13, Carl Jokl <carl...@gmail.com> wrote:

Was that the project that was mentioned in a lighting talk at the London JUG by any chance or a different one?

 

I presented it in a lightning talk at the LJC Open Conference, if that's the same JUG meetup, then that was me :)

 

I could see a benefit for immutable object for those that live in a Servlet container session cache especially if the web container could be clustered and everything in the Session needs to be replicated across servers. The mutable versions would play nicely with an ORM.

At this point I am not using any ORM and there are no domain objects at all in the system apart from some demonstration ones I created. I have been demoing with plain JDBC population (which is tedious) but it avoid having to add a dependency on the persistence API at this stage (though the mutable objects are ripe for modification in the future to add ORM annotations to them. 

At this point the work I have done may not go anywhere as the use of domain objects has not been well received so far. 

To be honest, if I had a greenfield opportunity, I don't know if I would pick an ORM. In my (admittedly limited) experience, ORM has caused as much pain as it has saved us from, but I wasn't around to experience the codebase without it, so it may be a 'greener grass' kind of thing. Also, if you're exclusively going to be mapping to objects, relational database may be the wrong choice, and it may be worth considering a nosql option. But, since you're having trouble convincing your team just to model the domain properly, nosql isn't likely to go down well.

HTH,

Graham

[Martijn Verburg]

I can't resist: Hibernate == Cake Mix - http://topsy.com/vimeo.com/28885655

Cheers,
Martijn

[Carl Jokl]

In all seriousness though, is this how badly Hibernate is viewed these
days? Having an ORM seemed to make sense to me and still does in
theory. I know in practice I have hit plenty of obscure cases or
problems in Hibernate but I am not sure I would throw it all out as a
waste of time just yet and also it is not as if Hibernate is the only
ORM around.

On Dec 21, 3:37 pm, Martijn Verburg <martijnverb...@gmail.com> wrote:
> I can't resist: Hibernate == Cake Mix -http://topsy.com/vimeo.com/28885655
>
> Cheers,
> Martijn
>
> On 21 December 2011 14:57, Graham Allan <grundlefl...@googlemail.com> wrote:

[Martijn Verburg]

Hi Carl,

I think that Hibernate (like any framework) has its place. It gets mocked probably more because of the countless abuses of it by developers who haven't quite understood it properly ("I can do foobar.save(); that is all I need to know").

Cheers,
Martijn

[Ricky Clarkson]

My current client dislikes Hibernate (not that I'm proposing it)
because most of their technical staff have DB experience more than
straight programming experience; even the Business Analysts can talk
in SQL. They worry that if Hibernate does something they don't expect
they won't be able to make the tweaks they want to, or export the
queries to SQL to be able to run parts manually.

iBatis has been tabled as something that doesn't even attempt to hide
the underlying SQL. I personally don't know the requirements for that
particular project yet so I'm not recommending anything, other than
not deciding on the technologies before at least saying what the
project is for.

[Fabrizio Giudici]

On Thu, 22 Dec 2011 00:51:51 +0100, Ricky Clarkson
<ricky.c...@gmail.com> wrote:

> My current client dislikes Hibernate (not that I'm proposing it)
> because most of their technical staff have DB experience more than
> straight programming experience; even the Business Analysts can talk
> in SQL. They worry that if Hibernate does something they don't expect
> they won't be able to make the tweaks they want to, or export the
> queries to SQL to be able to run parts manually.
>
> iBatis has been tabled as something that doesn't even attempt to hide
> the underlying SQL. I personally don't know the requirements for that
> particular project yet so I'm not recommending anything, other than
> not deciding on the technologies before at least saying what the
> project is for.

With iBatis you're more in control and can be a reasonable choice. But
these scenarios worry me at another level: if people are "reasoning in
SQL" they won't be designing in OO. Which is not a problem, of course, if
they are aware of what they are doing.

Same point for greenfield projects where people start first designing the
database. I'm still seeing this because when you're acquainted in doing
that for decades it's a strong habit, but indeed the database should be
designed after the core.

--
Fabrizio Giudici - Java Architect, Project Manager
Tidalwave s.a.s. - "We make Java work. Everywhere."
fabrizio...@tidalwave.it
http://tidalwave.it - http://fabriziogiudici.it

[Ricky Clarkson]

They are people who are more comfortable with SQL than code, so I don't see any harm in letting them design in terms of SQL.

That said, the real harm is that pretty much all development touches a shared database, with the risks that entails.

I'd rather add database access when needed, but then I think in code rather than SQL.

[Carl Jokl]

The demonstration domain classes that I had been working on went down
like a lead balloon. My supervisor thought the whole endeavour was a
waste of time and could not see any benefit. I was in the wrong
genuinely for having spent too much time on it. Not that I originally
intended to but it took a bit longer because I knew I could not use an
ORM and so experimented a bit with creating my own lazy loading proxy
class to get a referenced domain. Also working on it without
consulting him. I didn't because if feared he would shoot down the
whole idea before I had a proof of concept from which to demonstrate
how much easier it would be to code to an object with all the types
preserved than mess around with arrays of Strings or random String
values stored in the session. Also I might have been able to get some
other developers to back me up if I could demonstrate what I had in
mind rather than just talk about it. I am still fairly new and have
been working on bug fixes while learning the system. It seemed to be a
point in my employment when I would have more time to work on things
like this than later when I am up against pressing deadlines. Still
hindsight is always 20/20. I did a lot of work on it out of hours but
some of it was in hours.

I think the discussion is probably not going to go further from my Job
perspective. If I cannot seem to convince my technical manager of the
benefit then I can't very well keep working on the prototype and he
would see the commits to subversion even if I did it out of hours
(albeit I could work purely on it as a local copy) and I have lost
enthusiasm to be honest given how badly it went town.

If I thought the face to face conversation was sufficiently awkward,
today I found the scathing remarks made on JIRA when he first
discovered the classes and it had caused some problem on the test
server due to a missing dependency. I blame that partially on the
fragility of the build process using make and declaring every file and
directory individually which is both tedious and error prone.

I have taken my work out of subversion but made a local backup first
so I have not lost it.

I am annoyed at myself for things I see I did wrong but it did achieve
one thing which is answering my question about how much hope I can
have about making the system significantly better in the future. Sorry
for the tone of the post but I am in a perfectly foul mood right now
(and thinking of updating my Monster profile over Christmas). In the
mean time I will just have to take my String arrays and like it.

[ags]

Don't worry, List<Map<String, SometimesStringSometimesNot>> happens to me too ;-)

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

--

ags

[Ricky Clarkson]

I'd strongly suggest being more careful about what you post to this newsgroup.

If I was hiring and saw this I'd think you seemed to be unable to compromise and that you go complaining in forums rather than communicating with your colleagues.

That said, the above wouldn't be a no-hire for me, it'd just give me doubts and I'd ask some awkward questions.

More practically for your current job try to identify why they like everything to be strings. Sometimes there's a failed project in the past involving a technology you're proposing, or it's just that you're dealing with novice programmers.

There's usually a way of compromising such that you improve the situation even if it's not exactly what you imagined the endgame to be.

-----Original Message-----
From: Carl Jokl <carl...@gmail.com>
Sender: java...@googlegroups.com

[Graham Allan]

Hey Carl,

Not to be too harsh to someone who can't give their side of the story, but from your account it sounds like your supervisor is a dick.

It's fair enough to get annoyed if you're spending time on non-prioritised stuff - they pays their money they takes their choice. But if it's mostly on your own time he should be thanking you, not flaming you on a bug tracking system, presumably for the whole team to see. 

Have a good Christmas,

Graham

[Carl Jokl]

That is where I acknowledge my own fault in that on company time I am
at their digression as to what I should be spending it on. I think he
had every right to be angry about that because I wish I had just done
it all in my own time. One difficulty is that I have a desktop for
work and security won't permit me from working on the code on my own
laptop and I have no way of working on things at home. I can stay late
after work but am not able to lock up because I don't have a key or
alarm user meaning when the last person who can lock up goes I get
kicked out.

This is probably my favourite like from the JIRA comment but I will
take out the name of the company from the package:

"Hmmm .... I noticed these new "uk.co.x.model" classes. I happen to
dislike very much extensive use of model classes
which in my view is an over-engineered, unproductive waste of time
typical of code written by consultants. And, it's completely
inconsistent with the existing codebase."

You are right that it is totally inconsistent with the existing
codebase. I am glad of it because the existing code base is probably
the worsted structured, messy code I have worked on ignoring an entire
catalogue of best practices that I have taken for granted at other
companies. Unproductive waste of time typical of code written by
consultants. Ouch. I am glad I can laugh at this because otherwise I
could cry.

[Carl Jokl]

Back to the subject of Immutability with domains. What occurred to me
is that there is a difficulty in any domain relationship where Domain
A has a reference to Domain B and Domain B holds a reference back to
Domain A (where you don't want any duplication of objects). Due to any
standard database loading or even object instantiation requiring
either Domain A or Domain B to be created first, the first cannot get
a reference to the second when created this way and if it is immutable
then it cannot set the reference later. The only way I can think of
that I think would work is if Domain A creates Domain B in its
constructor passing a reference to itself and then assigning it to the
final internal field. This makes the domain loading a bit tricky as it
may require having some mutable objects or builders first and then
using those to hold to data needed to create one Domain and the other
in the first Domains constructor.

It made sense that this should work in my head last night as I lay
awake unable to sleep with too much on my mind. I was tired though so
I might have missed something. It might also be desirable to avoid
having two way references like this as much as possible anyway.

[Sebastian Himberger]

Hi Carl,

I posted a message to this thread but it somehow got lost. We have the same problem in a current project but we are not using a ORM but JSON for storage. We are using a builder to deserialize the JSON and create a immutable object out of it. I have an experiment up on GitHub. Maybe it is helpful to you: https://github.com/shimberger/jackson-builder-module

In JSON it is easy since the structure is always a tree and there are only parent/child relationships. This means we just have to construct the children before the parent. 

I somehow find that having complex object graphs make it difficult to modularize your application anyway. I tend to model references explizitly using IDs. Maybe I am just too much of a database person. This also get's around the whole lazy-loading issue. But I guess you loose a rich domain model

It is a very interesting issue discussion. Your thought makes sense to me. Bi-directional relationships seem to be an issue.

Merry Christmas,

Sebastian

[Roland Tepp]

I cant but help but thinking, this might just be a prime candidate for Daily WTF article...

[Carl Jokl]

I think my discovery of the day is in a CSV parser that has a comment
about how if the code below were written in C then it would use goto
in order to jump quickly from one large section to another but as goto
is not available in Java, instead it throws an exception to quickly
jump to another part of the code as part of the flow control. I think
I am falling deeper down the rabbit hole.

It does seem to bring the problem more into focus. I don't know if it
is a lack of awareness of accepted good practices (I am apprehensive
about saying "best practices" because I know of those who hate that
term and think "best practices" are generally subjective and end up
being corporate speak like leveraging synergies). It seems what I have
seen implies more and more a general attitude of "We know better" and
treatment of these design patterns and principles as unnecessary time
wasting exercises invented by consultants so that they can take more
time over things and therefore make more money. I also wonder if the
comment might have related to experience with the company actually
hiring a consultant to do something and no doubt the consultant would
probably have programmed rather differently to the regular
programmers.

I know also I should be careful because this is a public group and I
cannot be sure that my comments could not be discovered. As much as
perhaps I therefore might be better not to discuss current work issues
here, I have done so knowing the risks given that otherwise I would be
left feeling pretty isolated.

[Ricky Clarkson]

That method is how non-local returns, throws, breaks and continues worked in the BGGA closures prototype and how non-local returns work in Scala.

Not that I'd suggest it for user-level code. Use methods.

-----Original Message-----
From: Carl Jokl <carl...@gmail.com>
Sender: java...@googlegroups.com
Date: Tue, 3 Jan 2012 05:23:55
To: The Java Posse<java...@googlegroups.com>
Reply-To: java...@googlegroups.com