Insurance policies, etc. are complicated graphs even for a relational
database model. I am not convinced you have to use clojure's
functional data structures for these graphs. I've seen good ORM
frameworks run out of steam on insurance apps as well.
As part of the _processing_ of insurance
You might also look at Out of the Tar Pit (http://web.mac.com/
ben_moseley/frp/paper-v1_01.pdf) by Mosely and Marks. It's an
argument for the relational model that Stuart mentioned, with an
example. (Warning: the example is a few pages out of the 60-odd pages
of exposition and argument: great
re: clojure.contrib.datalog
Also note that some graph databases like AllegroGraph (not to over
promote that specific product, but it is free to use up to 50M triples
or somesuch)...
Anyway, such graph databases often provide a Prolog or Prolog-ish
inferencing capability (among other
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
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
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
Ha, ha, some object-oriented lessons are being rediscovered :)))
For example, you would have an opaque Person object, perhaps in a
Ref, and functions like get-name, set-name, get-policy, etc. The
underlying storage model can be whatever you want -- sets, SQL,
files, You just have to
On Sep 15, 6:54 am, Dragan Djuric draga...@gmail.com wrote:
Ha, ha, some object-oriented lessons are being rediscovered :)))
Precisely! Just because the language doesn't enforce information
hiding doesn't mean you can't do it.
-SS
--~--~-~--~~~---~--~~
You
Thank you all for your input. I think I will follow Stuart's advice
and go with something like the following, again using the example data
above.
(use 'clojure.set)
(def policies (ref #{{:id 3 :name x :holder 7 :vehicle 11}
{:id 4 :name y :holder 2 :vehicle
12}}))
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
I think that you made the mistake in the first step: you cannot
*change* a clojure's map. Thus, you cannot change one particular
snapshot of person's data. No problem up to this point. You can only
create a new map with some data reused. There lies the problem - how
to update the references to
We mainly use macros to create functions to deal with associations,
a bit like ActiveRecord except that it is not yet as dynamic. We do not
use the table meta data to find the associations
and create the finders, etc...
We want eventually to add stuff to clj-record to make it more like
Hi Brenton,
Nested maps are a good way to start, but they're pretty low level as
you want to do more complicated things. If you're talking about data
associations, the relational model is higher level and it's really
worth modeling your data in that way.
Relational data manipulation doesn't
Hi Brenton,
I think the simplest solution to this problem is to use functions
instead of maps. That is, instead of defining your API in terms of
maps with specific keys, define it in terms of functions that read/
write individual fields.
For example, you would have an opaque Person object,
14 matches
Mail list logo
