[Haskell-cafe] ORM for haskell?

[Rick R]

It has to do with treating groups of records from a table like an object.
You have the object Employee, which consists of rows from the Person table,
the Account table and the Building table.
When you instantiate the object. if you don't ask to view the Employee's
building information, it doesn't bother to retrieve it.

In the case you mention, the data hasn't yet been loaded, and even if it
were, it can be loaded with traditional transactional semantics (read only,
read with possible write, write, etc)


On Tue, Jun 30, 2009 at 2:29 PM, Daniel Peebles <pumpkingod at gmail.com>wrote:

> I don't have a good answer to your question, but I'm curious of how
> lazy loading of SQL-based records would work. It seems like having
> another user of the database modify your record before you've loaded
> it all could lead to an inconsistent record (assuming you've already
> loaded and memoized some fields and not others).
>
> On Tue, Jun 30, 2009 at 1:52 PM, Marc Weber<marco-oweber at gmx.de> wrote:
> > Some time ago I stumbled upon SQLAlchemy which is a great ORM wrapper
> > library for python. It has a nice syntax I'd like to see in a haskell
> > library as well.
> >
> > SQLAlchemy already provides some lazy features such as loading subitems
> > on access etc.
> >
> > All haskell SQL libraries I know only let you run SQL statements but not
> > much more. To start real business you no longer want to write many SQL
> > commands.
> >
> > Example why it matters:
> > schools - 1:n - teachers - 1:n - pupils
> >
> > If you want to list all schools which have a pupil with age > 3 you'd
> > write an sql query like this:
> >
> >  SELECT dictinct * FROM schools as s JOIN teachers t ON (t.school_id =
> s.id) JOIN pupils as p ON (p.teacher_id = t.id) WHERE p.age > 3
> >
> >  in SQLAlchemy it looks like this:
> >
>  session.query(School).join(School.teachers).join(Teacher.pupils).filter(Pupil.age
> > 3).all()
> >
> >  difference? Because SQLAlchemy knows about the relations you don't have
> >  to remember alias names. So there is no chance to get that wrong.
> >
> >
> > Another example: Updating the age of a pupil:
> >
> >  row = SELECT * FROM pupils where age = 13;
> >  UPDATE pupils SET age = 14 WHERE id = <the id you got above>
> >
> >  p = session.query(Pupil).filter(Pupil.age==13).one().age=14
> >  session.commit()
> >
> >  difference?
> >  You don't have to care about ids. you just assign a new value and tell
> >  the engine that it should commit.
> >  So again less chances to get something wrong.
> >
> >
> > What about trees (eg web site navigation)
> >
> >  id   |  title    | parent_id
> >  1   |  top      | null
> >  2   |  submenu  | 1
> >  3   |  submenu2 | 1
> >
> > should result in
> >
> > top
> >  - submenu
> >  - submenu2
> >
> > using SQLAlchemy you can just do
> >
> > parent = session.query('nodes').filter(Node.id = 1)
> >
> > def print(node):
> >  print node.title
> >  print node.subnodes # this will run a subquery automatically for you
> returning submenu{,2}
> >
> > Again no sql. No chance to get something wrong?
> >
> > You can skim the manual to get a better idea how SQLAlchemy works
> > http://www.sqlalchemy.org/docs/05/sqlalchemy_0_5_5.pdf
> >
> > I have to admit that I haven't used SQLAlchemy in a real project yet.
> > However I can imagine doing so. Comparing this to what we have on
> > hackage I'd say some work has to be done to get close to SQLAlchemy.
> >
> > The backend doesn't have to be a relational database. However I'd like
> > to use this kind of abstraction in haskell.
> >
> > Is there anyone interested in helping building a library which
> > a) let's you define kind of model of you data
> > b) let's you store you model in any backend (maybe a relational
> >    database)
> > c) does static checking of your queries at compilation time?
> >
> > Right now I'd say the best way to go is define the model in the
> > application and not get the scheme from an existing database because
> > there is not way to store all scheme details within a relational model.
> > I think SQLAlchemy does it right by providing a way to define the model
> > in python.
> >
> > Of course haskell doesn't have "objects" to store. But GADTs could be
> > stored (data Foo = ...)
> >
> > So are there any volunteers who are interested in helping writing this
> > kind of storage solution for haskell which could be used in real world
> > business apps?
> >
> > Maybe this does already exist and I've missed it?
> >
> > Marc Weber
> > _______________________________________________
> > Haskell-Cafe mailing list
> > Haskell-Cafe at haskell.org
> > http://www.haskell.org/mailman/listinfo/haskell-cafe
> >
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>



-- 
"The greatest obstacle to discovering the shape of the earth, the
continents, and the oceans was not ignorance but the illusion of knowledge."

- Daniel J. Boorstin
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/haskell-cafe/attachments/20090630/e6e0e608/attachment.html