From sjatkins at mac.com Tue Oct 2 04:19:48 2007 From: sjatkins at mac.com (Samantha Atkins) Date: Mon, 1 Oct 2007 21:19:48 -0700 Subject: [postmodern-devel] is postmodern thread safe In-Reply-To: References: <22221009-6367-4B8C-BC51-695EA7DC74BD@mac.com> Message-ID: <2D1974BF-1970-4A10-8997-D516698176D3@mac.com> On Sep 26, 2007, at 2:44 AM, Marijn Haverbeke wrote: > Hold it! The competition is advertising on *my* list now? Hah, never > mind, CL-RDBMS is a nice system, but to answer your question about > Postmodern: Yes, it is thread-safe, as long as you do not have two > threads use the same connection object at the same time. Using > WITH-CONNECTION, it is easy to give each thread its own connection. > The only part of the library that uses global mutable state is the > connection pool, and I used bordeaux-threads' mutexes to prevent > problems there. > Is WITH-CONNECTION getting threads out of a pool? It seemed to optionally to do that but my early reading also made me wonder if those were active connections or still had some overhead before they could be used. My own project idea was to take my ample (20+ years) of object persistence experience and produce a oodbms equivalent layer that can sit on any relational or many other underlying stores. The ideas is that this layer can be used by any language front end to as transparently as possible persist objects, structures and relationships between them with consistent transaction support, concurrency, caching and throughput mostly independent of front end language efficiency. Obviously this layer needs to be seriously multi-threaded. I sometimes have doubts about doing this project in Lisp because things like threading support are not consistent and dependable on all platforms using non-proprietary Lisp. Lisp is attractive to me for the mileage I can get in the way of generated specialized code and on the fly refactoring and other reactive programming tricks. It also can come in very handy for offering a very full object query language that produces much more optimal code than less capable languages can support. But the meat of such a layer could certainly easily be done in C# (I most of that "meat" in Java a while back) with much more portability and some serious other advantages like being able to be used fully in a single process for any .net/mono capable language. - samantha From ryszard.szopa at gmail.com Tue Oct 2 06:54:03 2007 From: ryszard.szopa at gmail.com (Ryszard Szopa) Date: Tue, 2 Oct 2007 08:54:03 +0200 Subject: [postmodern-devel] is postmodern thread safe In-Reply-To: <2D1974BF-1970-4A10-8997-D516698176D3@mac.com> References: <22221009-6367-4B8C-BC51-695EA7DC74BD@mac.com> <2D1974BF-1970-4A10-8997-D516698176D3@mac.com> Message-ID: <19e19e410710012354r16335fc9u765a8890311ca58d@mail.gmail.com> On 10/2/07, Samantha Atkins wrote: > Is WITH-CONNECTION getting threads out of a pool? It seemed to > optionally to do that but my early reading also made me wonder if > those were active connections or still had some overhead before they > could be used. My own project idea was to take my ample (20+ years) WITH-CONNECTION (and in fact any function/macro that deals with a connection) takes a POOLEDP argument. If it is non-NIL, a connection is recycled from the connection pool (if available). I don't *know* (in the sense I haven't really digged in that code or made thorough tests) if it works, but it *seems* to work and I kind of trust Marijn when he says it works. > of object persistence experience and produce a oodbms equivalent layer > that can sit on any relational or many other underlying stores. The > ideas is that this layer can be used by any language front end to as > transparently as possible persist objects, structures and > relationships between them with consistent transaction support, > concurrency, caching and throughput mostly independent of front end > language efficiency. Well, Common Lisp thanks to CLOS and the MetaObject Protocol [1] seems like the perfect language to write something like that. Postmodern is also a good choice, because its "getting in the way" factor is very, very low (I think that keeping it maximally unobtrusive was one of Marijn's design goals). The problematic part in writing an object persistency library remains (at least for me: I'm working on Submarine [2]) maintaining the balance between use comfort and efficiency. To make a long story short, making things happen naturally from the CLOS programmer (and I think any object system programmer) point of view sometimes leads to producing highly inefficient code... For an extreme example, one could easily overload slot-setting/slot-reading by updating/reading the values of columns in some table, and that could be (from the programmer's point of view) quite comfortable. Of course, this would be inefficient to death. I still have hope, however, that there exist smart ways of generating nice SQL code under the hood. I am still astonished by the stupidity of some fragments of my own Postmodern/SQL code in Submarine, so I predict I still have plenty of room for optimization, without loosing the nice features or a rewrite from scratch :) After all, Common Lisp is such a nice language for generating code in lesser ;) languages, like SQL. > Obviously this layer needs to be seriously multi-threaded. I > sometimes have doubts about doing this project in Lisp because things > like threading support are not consistent and dependable on all > platforms using non-proprietary Lisp. Lisp is attractive to me for > the mileage I can get in the way of generated specialized code and on > the fly refactoring and other reactive programming tricks. It also > can come in very handy for offering a very full object query language > that produces much more optimal code than less capable languages can > support. But the meat of such a layer could certainly easily be done > in C# (I most of that "meat" in Java a while back) with much more > portability and some serious other advantages like being able to be > used fully in a single process for any .net/mono capable language. There are Bordeaux threads, which is a semi-standard thread compatibility layer between different CL implementations. Threads in CL remain a bit tricky, though. Best regards, -- Richard [1] Bear in mind, however, that MOP is not standardized and its implementation may differ drastically between different CL implementations. Of course, there is Closer-MOP, but that doesn't solve all the problems (e.g. slot objects in Lispworks don't know which class they are belong to, while in SBCL they do). [2] My very own object persistency library: http://common-lisp.net/project/submarine/. For the record, I *did* resist the temptation of advertising it in this thread ;-) (sometimes I have the feeling that writing an object persistency layer should be consed to every Lisp hacker's TODO list, the one already containing writing his/her own scheme dialect and planting a tree). -- http://szopa.tasak.gda.pl/ From rm at seid-online.de Wed Oct 17 14:35:56 2007 From: rm at seid-online.de (Ralf Mattes) Date: Wed, 17 Oct 2007 16:35:56 +0200 Subject: [postmodern-devel] Multiple inner joins ... Message-ID: <1192631756.6413.14.camel@localhost.localdomain> Hello list, I'm trying to generate a query similar to the following: SELECT foo, bar, baz FROM (SELECT foo FROM ... WHERE ...) AS tmp1 INNER JOIN (SELECT bar FROM ... WHERE ...) AS tmp2 ON (tmp1.id = tmp2.id) INNER JOIN (SELECT baz FROM ... WHERE ...) AS tmp3 ON (tmp2.id = tmp3.id) How can I express this in S-SQL syntax? TIA Ralf Mattes From marijnh at gmail.com Wed Oct 17 15:09:05 2007 From: marijnh at gmail.com (Marijn Haverbeke) Date: Wed, 17 Oct 2007 17:09:05 +0200 Subject: [postmodern-devel] Multiple inner joins ... In-Reply-To: <1192631756.6413.14.camel@localhost.localdomain> References: <1192631756.6413.14.camel@localhost.localdomain> Message-ID: Hello Ralf, Try... (s-sql:sql (:select 'foo 'bar 'baz :from (:as (:select 'foo :from 'x :where 'x) 'tmp1) :inner-join (:as (:select 'bar :from 'x :where 'x) 'tmp2) :on (:= 'tmp1.id 'tmp2.id) :inner-join (:as (:select 'baz :from 'x :where 'x) 'tmp3) :on (:= 'tmp2.id 'tmp3.id))) ... which gives ... "(SELECT foo, bar, baz FROM (SELECT foo FROM x WHERE x) AS tmp1 INNER JOIN (SELECT bar FROM x WHERE x) AS tmp2 ON (tmp1.id = tmp2.id) INNER JOIN (SELECT baz FROM x WHERE x) AS tmp3 ON (tmp2.id = tmp3.id))" Cheers, Marijn From rm at seid-online.de Wed Oct 17 15:36:28 2007 From: rm at seid-online.de (Ralf Mattes) Date: Wed, 17 Oct 2007 17:36:28 +0200 Subject: [postmodern-devel] Multiple inner joins ... In-Reply-To: References: <1192631756.6413.14.camel@localhost.localdomain> Message-ID: <1192635388.6413.17.camel@localhost.localdomain> On Wed, 2007-10-17 at 17:09 +0200, Marijn Haverbeke wrote: > Hello Ralf, > Hey, thanks! That was a fast reply ;-) Yes, that seems to work fine. Thanks a lot RalfD > Try... > > (s-sql:sql (:select 'foo 'bar 'baz :from (:as (:select 'foo :from 'x > :where 'x) 'tmp1) > :inner-join (:as (:select 'bar :from 'x :where 'x) 'tmp2) :on (:= > 'tmp1.id 'tmp2.id) > :inner-join (:as (:select 'baz :from 'x :where 'x) 'tmp3) :on (:= > 'tmp2.id 'tmp3.id))) > > ... which gives ... > > "(SELECT foo, bar, baz FROM (SELECT foo FROM x WHERE x) AS tmp1 INNER > JOIN (SELECT bar FROM x WHERE x) AS tmp2 ON (tmp1.id = tmp2.id) INNER > JOIN (SELECT baz FROM x WHERE x) AS tmp3 ON (tmp2.id = tmp3.id))" > > Cheers, > Marijn