Hi Marc Weber
Hi Mads!
Hi Marc Weber
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.
Could you not do in SQL:
UPDATE pupils SET age = 14 WHERE age = 13 Of course. But: you can pass around that pupil object to another function and still assign a new age
On Tue, Jun 30, 2009 at 11:49:40PM +0200, Mads Lindstrøm wrote: then run session.commit(). When passing around the pupile you can follow the relation_ships (relations?) back to school.
def doSomething(pupil): pupil['age'] = 13 pupil.teacher.school.rating += 1
doSomething(session.query(Pupil).filter(Pupil.age==13)) session.commit()
Now how would you do this using SQL?
As far as I know, you cannot. And it is very nice. On the other hand you sometimes want to execute more of the logic on the DBMS, as it leads to better performance. But maybe we can somehow have our cake and eat it too. E.g. if the user still have some control about where the logic is executed.
Sorry about the confustion (relation / relation-ship). I mixed up the terminology. Anyway I guess you can see here how powerful an ORM can be and why we should write such a library for haskell.
Don't be sorry about that. I know people often confuse the terms and I could have replied just asking if you had not swapped the two terms. In my native language relation can mean both relation and to relationship. Guess, it is the same in other languages...
I think it's very hard to invent such a short synax in haskell cause you have to take monads into account etc..
And it matters how much time you have to spend writing code.
Yes and yes. I think (my gut tells me so) you will need to use Template Haskell, if you want something as succinct as the Python code you showed. Or maybe if you give up type safety, but I guess your are not willing to do that. But it could be fun (and challenging) coming up with something really nice.
Thanks for your feedback. I hope there will be some more.
Marc Weber
I may have sounded a bit negative in my previous mails. But I really can see something cool about what you describe. That said, I think people are sometimes too eager to replace SQL. As you properly are already aware, SQL+Relational databases has some very nice properties (list below is form the top of my head, there are other advantages): * They are accessed with a declarative language (SQL) * They can make high-level optimization automatically and guided by the user * They can, transparently, execute queries/updates using multiple servers/CPUs. It may require some changes to the database, but it can be done without changing your SQL * They are based on a nice theoretical foundation * If databases are normalized properly, data are a lot more transparent than other ways of organizing data. At least other ways I have seen. * Normalization provides a lot less ambiguous guidance, than other "development methodologies". * Transaction support But as you point out yourself, everything is not rosy. And in addition to what you write, all the (un)marshaling you need when accessing databases from Haskell is quite cumbersome. And I realize that you are not trying to replace RDBs, just building a nicer interface to them. I am just concerned that some of the nice properties are lost in the process. I think my main concern comes from seeing people create databases, by automatically generating tables from OO-classes. They invariably ends up with something not nearly as nice, as if they had constructed the database in a more traditional fashion. To summarize, what you propose is cool. Just do not throw the baby out with the bathwater. Greetings, Mads Lindstrøm