You're right about that.
I commented to a general solution. The point is that the community has
to develop a set of patterns/practices/whatever for this use case
since almost any "ordinary" application software has to solve it.
For 101 questions like this, there has to be at least one or more
straight answers with code examples. At least if we want Clojure to be
picked up by the general Java community. Not everyone has to compute
Fibonacci's sequence but everyone has to support some customers buying
some products ;)
On Sep 17, 12:46 am, eyeris <drewpvo...@gmail.com> wrote:
> Like I said, this applies if you already have a data model mapped to
> an object model via Hibernate. You can leverage that mapping for the
> time being and write what code originally prompted you to take up
> clojure. This is especially attractive when you are introducing
> clojure into a production program that is in production.
>
> Wrapping your java objects with a clojure API does not require you to
> retain the semantics. It only requires you to translate them to
> clojure, which I think would be easier than translating the relational
> database semantics to clojure.
>
> If you don't already have your data mapped to an object model, then
> it's likely not worth the effort. In that case, look into one of the
> other suggestions on this thread.
>
> On Sep 16, 5:24 pm, Dragan Djuric <draga...@gmail.com> wrote:
>
> > Yes, but then it's just Java semantics disguised in a lispy syntax.
> > What I really like in Clojure are immutable data structures,
> > multimethods, closures, macros etc.
> > If we have to use Hibernate and Spring and all that (which is not bad,
> > but still looks too complex and bloated from the perspective of FP)
> > then why bother with Clojure...
> > Don't get me wrong: I think that Java interop is the most important
> > feature of Clojure, but for calling libraries, not building on
> > frameworks.
>
> > On Sep 16, 9:50 pm, eyeris <drewpvo...@gmail.com> wrote:
>
> > > If you already have a data model mapped to an object model via
> > > Hibernate (or similar Java-based product), you could simply wrap a
> > > clojure API around those classes via the Java interop. However, I
> > > don't know of an example of published code that does this.
>
> > > On Sep 14, 4:34 pm, Brenton <bashw...@gmail.com> wrote:
>
> > > > I am starting to write a large web application using Clojure and
> > > > Compojure and am running into some design trouble while designing my
> > > > data model. To illustrate my problem I am going to make up some fake
> > > > data. Suppose you are writing an Insurance application which has the
> > > > tables Policy, Person and Vehicle. A policy has a person that is the
> > > > policy holder. A policy also has many vehicles. Each vehicle has a
> > > > person that is the primary driver. Most of the time the primary driver
> > > > is the same as the policy holder. If I were using one of the usual
> > > > object-relational mapping frameworks, (Hibernate, ActiveRecord) when I
> > > > load a policy I would get an object graph. If the person who is the
> > > > policy holder is the same as the person who is the primary driver of
> > > > the vehicle then the loaded Person object would be the same object. If
> > > > I change the address of the policy holder the primary driver's address
> > > > will also be changed.
>
> > > > How do people deal with this sort of thing in a Clojure application
> > > > (or any other functional language)? At first I thought that it would
> > > > be easy and I would just use nested maps. But this causes all kinds of
> > > > problems. If I load the data into nested maps I now have two distinct
> > > > maps for the same person. If I change one of them, the other is not
> > > > updated. If I try to save this map back to the database, which person
> > > > map has the correct data? It is also awkward to update the person in
> > > > the first place. In Java you would just go policy.getPolicyHolder
> > > > ().setAddress("..."). In Clojure you would have to do something like
> > > > (assoc policy :holder (assoc (:holder policy) :address "...")).
>
> > > > I have a feeling that there is a more "functional" way to do this sort
> > > > of thing. My question is, how to other people deal with this? The only
> > > > thing that I can think of is that I would avoid using nested maps to
> > > > model the database associations. I would load the policy into a map.
> > > > Then if I need the person, I would load that into a separate map. That
> > > > may be the correct functional approach. I was just asking in case
> > > > there is some really cool thing that people do that I don't know
> > > > about.
>
> > > > I had a look at clj-record to see how associations where handled. It
> > > > looks like nested maps are avoided here. Instead functions are created
> > > > to retrieve the associated data. Is the correct way of this this?
>
> > > > Thank you,
> > > > Brenton
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated - please be patient with your
first post.
To unsubscribe from this group, send email to
clojure+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
-~----------~----~----~----~------~----~------~--~---
