It has to do with treating groups of records from a table like an object. <br>You have the object Employee, which consists of rows from the Person table, the Account table and the Building table. <br>When you instantiate the object. if you don&#39;t ask to view the Employee&#39;s building information, it doesn&#39;t bother to retrieve it. <br>
<br>In the case you mention, the data hasn&#39;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)  <br><br><br><div class="gmail_quote">
On Tue, Jun 30, 2009 at 2:29 PM, Daniel Peebles <span dir="ltr">&lt;<a href="mailto:pumpkingod@gmail.com">pumpkingod@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I don&#39;t have a good answer to your question, but I&#39;m curious of how<br>
lazy loading of SQL-based records would work. It seems like having<br>
another user of the database modify your record before you&#39;ve loaded<br>
it all could lead to an inconsistent record (assuming you&#39;ve already<br>
loaded and memoized some fields and not others).<br>
<div><div></div><div class="h5"><br>
On Tue, Jun 30, 2009 at 1:52 PM, Marc Weber&lt;<a href="mailto:marco-oweber@gmx.de">marco-oweber@gmx.de</a>&gt; wrote:<br>
&gt; Some time ago I stumbled upon SQLAlchemy which is a great ORM wrapper<br>
&gt; library for python. It has a nice syntax I&#39;d like to see in a haskell<br>
&gt; library as well.<br>
&gt;<br>
&gt; SQLAlchemy already provides some lazy features such as loading subitems<br>
&gt; on access etc.<br>
&gt;<br>
&gt; All haskell SQL libraries I know only let you run SQL statements but not<br>
&gt; much more. To start real business you no longer want to write many SQL<br>
&gt; commands.<br>
&gt;<br>
&gt; Example why it matters:<br>
&gt; schools - 1:n - teachers - 1:n - pupils<br>
&gt;<br>
&gt; If you want to list all schools which have a pupil with age &gt; 3 you&#39;d<br>
&gt; write an sql query like this:<br>
&gt;<br>
&gt;  SELECT dictinct * FROM schools as s JOIN teachers t ON (t.school_id = <a href="http://s.id" target="_blank">s.id</a>) JOIN pupils as p ON (p.teacher_id = <a href="http://t.id" target="_blank">t.id</a>) WHERE p.age &gt; 3<br>

&gt;<br>
&gt;  in SQLAlchemy it looks like this:<br>
&gt;  session.query(School).join(School.teachers).join(Teacher.pupils).filter(Pupil.age &gt; 3).all()<br>
&gt;<br>
&gt;  difference? Because SQLAlchemy knows about the relations you don&#39;t have<br>
&gt;  to remember alias names. So there is no chance to get that wrong.<br>
&gt;<br>
&gt;<br>
&gt; Another example: Updating the age of a pupil:<br>
&gt;<br>
&gt;  row = SELECT * FROM pupils where age = 13;<br>
&gt;  UPDATE pupils SET age = 14 WHERE id = &lt;the id you got above&gt;<br>
&gt;<br>
&gt;  p = session.query(Pupil).filter(Pupil.age==13).one().age=14<br>
&gt;  session.commit()<br>
&gt;<br>
&gt;  difference?<br>
&gt;  You don&#39;t have to care about ids. you just assign a new value and tell<br>
&gt;  the engine that it should commit.<br>
&gt;  So again less chances to get something wrong.<br>
&gt;<br>
&gt;<br>
&gt; What about trees (eg web site navigation)<br>
&gt;<br>
&gt;  id   |  title    | parent_id<br>
&gt;  1   |  top      | null<br>
&gt;  2   |  submenu  | 1<br>
&gt;  3   |  submenu2 | 1<br>
&gt;<br>
&gt; should result in<br>
&gt;<br>
&gt; top<br>
&gt;  - submenu<br>
&gt;  - submenu2<br>
&gt;<br>
&gt; using SQLAlchemy you can just do<br>
&gt;<br>
&gt; parent = session.query(&#39;nodes&#39;).filter(Node.id = 1)<br>
&gt;<br>
&gt; def print(node):<br>
&gt;  print node.title<br>
&gt;  print node.subnodes # this will run a subquery automatically for you returning submenu{,2}<br>
&gt;<br>
&gt; Again no sql. No chance to get something wrong?<br>
&gt;<br>
&gt; You can skim the manual to get a better idea how SQLAlchemy works<br>
&gt; <a href="http://www.sqlalchemy.org/docs/05/sqlalchemy_0_5_5.pdf" target="_blank">http://www.sqlalchemy.org/docs/05/sqlalchemy_0_5_5.pdf</a><br>
&gt;<br>
&gt; I have to admit that I haven&#39;t used SQLAlchemy in a real project yet.<br>
&gt; However I can imagine doing so. Comparing this to what we have on<br>
&gt; hackage I&#39;d say some work has to be done to get close to SQLAlchemy.<br>
&gt;<br>
&gt; The backend doesn&#39;t have to be a relational database. However I&#39;d like<br>
&gt; to use this kind of abstraction in haskell.<br>
&gt;<br>
&gt; Is there anyone interested in helping building a library which<br>
&gt; a) let&#39;s you define kind of model of you data<br>
&gt; b) let&#39;s you store you model in any backend (maybe a relational<br>
&gt;    database)<br>
&gt; c) does static checking of your queries at compilation time?<br>
&gt;<br>
&gt; Right now I&#39;d say the best way to go is define the model in the<br>
&gt; application and not get the scheme from an existing database because<br>
&gt; there is not way to store all scheme details within a relational model.<br>
&gt; I think SQLAlchemy does it right by providing a way to define the model<br>
&gt; in python.<br>
&gt;<br>
&gt; Of course haskell doesn&#39;t have &quot;objects&quot; to store. But GADTs could be<br>
&gt; stored (data Foo = ...)<br>
&gt;<br>
&gt; So are there any volunteers who are interested in helping writing this<br>
&gt; kind of storage solution for haskell which could be used in real world<br>
&gt; business apps?<br>
&gt;<br>
&gt; Maybe this does already exist and I&#39;ve missed it?<br>
&gt;<br>
&gt; Marc Weber<br>
&gt; _______________________________________________<br>
&gt; Haskell-Cafe mailing list<br>
&gt; <a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
&gt; <a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
&gt;<br>
_______________________________________________<br>
Haskell-Cafe mailing list<br>
<a href="mailto:Haskell-Cafe@haskell.org">Haskell-Cafe@haskell.org</a><br>
<a href="http://www.haskell.org/mailman/listinfo/haskell-cafe" target="_blank">http://www.haskell.org/mailman/listinfo/haskell-cafe</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>&quot;The greatest obstacle to discovering the shape of the earth, the continents, and the oceans was not ignorance but the illusion of knowledge.&quot; <br>- Daniel J. Boorstin<br>
<br>