From superdog at budzianowski.net  Thu Jun  5 22:39:08 2008
From: superdog at budzianowski.net (Roman Budzianowski)
Date: Thu, 5 Jun 2008 15:39:08 -0700
Subject: [postmodern-devel] dao functionality
Message-ID: <37CB2BEF-F3A7-4211-A1FB-5091F63A99AF@budzianowski.net>

Hi everybody,

I have decided to use the postmodern library to basically dump and  
then keep updating a large in memory object database into Postgres.
I am coming from the lisp side (my knowledge of rdb is limited).

I am wondering if the dao metaclass would allow me to define a table  
like the 'enemy' example. In particular is it possible to  
specify :foreign-key?

I don't intend to keep my objects in memory using dao class. I just  
want to use it to create tables and then to do inserts and updates.

Should I use S-SQL and sql-compile instead?

Thanks,

Roman




From marijnh at gmail.com  Thu Jun  5 23:13:40 2008
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Fri, 6 Jun 2008 01:13:40 +0200
Subject: [postmodern-devel] dao functionality
In-Reply-To: <37CB2BEF-F3A7-4211-A1FB-5091F63A99AF@budzianowski.net>
References: <37CB2BEF-F3A7-4211-A1FB-5091F63A99AF@budzianowski.net>
Message-ID: <befaa7aa0806051613k59d75505t4bae2d93183ce529@mail.gmail.com>

Hi Roman,

The DAO class -> table definition system is (intentionally) very
limited. The way I use it is for providing the basic table definition,
which I then extend with "create index", "create constraint", etc
commands. If you are not going to use them, there's really no reason
to define DAO classes.

Regards,
Marijn



On Fri, Jun 6, 2008 at 12:39 AM, Roman Budzianowski
<superdog at budzianowski.net> wrote:
> Hi everybody,
>
> I have decided to use the postmodern library to basically dump and then keep
> updating a large in memory object database into Postgres.
> I am coming from the lisp side (my knowledge of rdb is limited).
>
> I am wondering if the dao metaclass would allow me to define a table like
> the 'enemy' example. In particular is it possible to specify :foreign-key?
>
> I don't intend to keep my objects in memory using dao class. I just want to
> use it to create tables and then to do inserts and updates.
>
> Should I use S-SQL and sql-compile instead?
>
> Thanks,
>
> Roman
>
>
> _______________________________________________
> postmodern-devel mailing list
> postmodern-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
>


From superdog at budzianowski.net  Fri Jun  6 20:26:39 2008
From: superdog at budzianowski.net (Roman Budzianowski)
Date: Fri, 6 Jun 2008 13:26:39 -0700
Subject: [postmodern-devel] sql-op :raw
Message-ID: <F59E6B64-A4D7-47BE-AECB-A0D9CE579417@budzianowski.net>

Hi Marijn,

The following fails:

(sql (:DROP-TABLE 'MANUFACTURERS (:RAW "cascade")))

with

Passed 1 too many arguments for arglist (S-SQL::NAME)

Is :raw applicable only in certain contexts? Obviously this is just  
example - I am trying to build it in run time.

Thanks,

Roman


From marijnh at gmail.com  Fri Jun  6 21:08:43 2008
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Fri, 6 Jun 2008 23:08:43 +0200
Subject: [postmodern-devel] sql-op :raw
In-Reply-To: <F59E6B64-A4D7-47BE-AECB-A0D9CE579417@budzianowski.net>
References: <F59E6B64-A4D7-47BE-AECB-A0D9CE579417@budzianowski.net>
Message-ID: <befaa7aa0806061408p793720c8w764cff191747eb8d@mail.gmail.com>

Hello Roman,

:raw may only appear in places where S-SQL already expects some form.
:drop-table only expects a single argument. In this case, you're
probably better off just using format to build a query, since there's
nothing complicated going on, but if you have other kinds of queries
where s-sql's syntax is too limited, let me know, and I'll see if I
can add support for them.

Cheers,
Marijn


On Fri, Jun 6, 2008 at 10:26 PM, Roman Budzianowski
<superdog at budzianowski.net> wrote:
> Hi Marijn,
>
> The following fails:
>
> (sql (:DROP-TABLE 'MANUFACTURERS (:RAW "cascade")))
>
> with
>
> Passed 1 too many arguments for arglist (S-SQL::NAME)
>
> Is :raw applicable only in certain contexts? Obviously this is just example
> - I am trying to build it in run time.
>
> Thanks,
>
> Roman
> _______________________________________________
> postmodern-devel mailing list
> postmodern-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
>


From superdog at budzianowski.net  Sat Jun  7 17:02:58 2008
From: superdog at budzianowski.net (Roman Budzianowski)
Date: Sat, 7 Jun 2008 10:02:58 -0700
Subject: [postmodern-devel] prepare macro syntax
Message-ID: <AA91DEAC-C7C7-4093-96E5-FA8B30A25286@budzianowski.net>

Hi Marijn,

(prepare q) where q is bound to a query works fine, however
(prepare (get 'foo 'query)) doesn't complain, but generates incorrect  
closure.
Easy workaround, but is this a bug?

Thanks,

Roman



From marijnh at gmail.com  Sun Jun  8 01:49:22 2008
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Sat, 7 Jun 2008 18:49:22 -0700
Subject: [postmodern-devel] prepare macro syntax
In-Reply-To: <AA91DEAC-C7C7-4093-96E5-FA8B30A25286@budzianowski.net>
References: <AA91DEAC-C7C7-4093-96E5-FA8B30A25286@budzianowski.net>
Message-ID: <befaa7aa0806071849s197f118ame16459b52fda0842@mail.gmail.com>

Hi Roman,

I wouldn't even have expected the first thing to work -- or is the
query a string? .. If it is a string, then the second one should
probably work too. This behaviour is not intentional in any case. I
won't be able to look into it this week, but I'll get back to you.

Cheers,
Marijn


On Sat, Jun 7, 2008 at 10:02 AM, Roman Budzianowski
<superdog at budzianowski.net> wrote:
> Hi Marijn,
>
> (prepare q) where q is bound to a query works fine, however
> (prepare (get 'foo 'query)) doesn't complain, but generates incorrect
> closure.
> Easy workaround, but is this a bug?
>
> Thanks,
>
> Roman
>
> _______________________________________________
> postmodern-devel mailing list
> postmodern-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
>


From superdog at budzianowski.net  Sun Jun  8 02:01:53 2008
From: superdog at budzianowski.net (Roman Budzianowski)
Date: Sat, 7 Jun 2008 19:01:53 -0700
Subject: [postmodern-devel] prepare macro syntax
In-Reply-To: <befaa7aa0806071849s197f118ame16459b52fda0842@mail.gmail.com>
References: <AA91DEAC-C7C7-4093-96E5-FA8B30A25286@budzianowski.net>
	<befaa7aa0806071849s197f118ame16459b52fda0842@mail.gmail.com>
Message-ID: <3883A4C7-F9D2-4515-AEFF-AB7B55019463@budzianowski.net>

Right, it threw me off. I assumed that the arg is not evaluated.
But, then it is... Wrapping it in let and binding the arg makes it work.

On Jun 7, 2008, at 6:49 PM, Marijn Haverbeke wrote:

> Hi Roman,
>
> I wouldn't even have expected the first thing to work -- or is the
> query a string? .. If it is a string, then the second one should
> probably work too. This behaviour is not intentional in any case. I
> won't be able to look into it this week, but I'll get back to you.
>
> Cheers,
> Marijn
>
>
> On Sat, Jun 7, 2008 at 10:02 AM, Roman Budzianowski
> <superdog at budzianowski.net> wrote:
>> Hi Marijn,
>>
>> (prepare q) where q is bound to a query works fine, however
>> (prepare (get 'foo 'query)) doesn't complain, but generates incorrect
>> closure.
>> Easy workaround, but is this a bug?
>>
>> Thanks,
>>
>> Roman
>>
>> _______________________________________________
>> postmodern-devel mailing list
>> postmodern-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
>>
> _______________________________________________
> postmodern-devel mailing list
> postmodern-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel



From nablaone at gmail.com  Sun Jun  8 21:00:31 2008
From: nablaone at gmail.com (=?UTF-8?Q?Rafa=C5=82_Strzali=C5=84ski?=)
Date: Sun, 8 Jun 2008 23:00:31 +0200
Subject: [postmodern-devel] Table extra options in DAO definition
Message-ID: <f1384930806081400v4b2387b3m768374c8efe64dc8@mail.gmail.com>

Hi,

I'm attaching a  patch that allows to add table extra options ( :check
:unique ..) to a DAO definition.

Sample:

(defclass account ()
  ((id :col-type serial )
   (login :col-type (varchar 255) :accessor login :initarg :login)
   (password :col-type (varchar 255) :accessor password :initarg :password)
   (created_at :col-type timestamp :accessor created-at :initform
(now-timestamp)))
  (:unique name)
  (:metaclass dao-class)
  (:keys id)
  (:extra-options (:unique login))
  (:table-name account.account))


-- 
Best regards,
Rafal Strzalinski (nabla)
http://nablaone.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pm-dao-definition-extra-options.patch
Type: text/x-diff
Size: 1021 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/postmodern-devel/attachments/20080608/6c8a8755/attachment.patch>

From superdog at budzianowski.net  Mon Jun  9 23:46:05 2008
From: superdog at budzianowski.net (Roman Budzianowski)
Date: Mon, 9 Jun 2008 16:46:05 -0700
Subject: [postmodern-devel] db-null problem
Message-ID: <85147F5E-9422-4EB1-8B41-00B9DB8547DB@budzianowski.net>

There seems to be a problem with exporting of 'db-null type:

CL-USER> (pomo:sql (:create-table foo
	((age :type (or db-null integer) :default :null))))
"CREATE TABLE foo (age OR NOT NULL DEFAULT NULL)"  =========> error!

CL-USER> (in-package :pomo)
#<The POSTMODERN package>
POMO> (pomo:sql (:create-table foo
	((age :type (or db-null integer) :default :null))))
"CREATE TABLE foo (age INTEGER DEFAULT NULL)"
POMO>

Roman


From marijnh at gmail.com  Fri Jun 13 03:28:48 2008
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Thu, 12 Jun 2008 20:28:48 -0700
Subject: [postmodern-devel] Table extra options in DAO definition
In-Reply-To: <f1384930806081400v4b2387b3m768374c8efe64dc8@mail.gmail.com>
References: <f1384930806081400v4b2387b3m768374c8efe64dc8@mail.gmail.com>
Message-ID: <befaa7aa0806122028l6024a442i5bf8c2c1d3ee66f5@mail.gmail.com>

Hi Rafal,

Thanks for the patch. I don't have time to look at it right now but
I'll get back to you in a week or so. Chances are, though, that I
won't be including it as is. Did you ever use Postmodern before
version 1.10? The deftable form I had was going in this same
direction, but it became a mess, so I decided to separate the 'class
definition' part form the 'table definition' part. A feature similar
to your patch that I have been thinking about including is to add
something specifically for adding extra indices, sequences, and
constraints to a table -- I'm already using something like it in all
my major postmodern-using projects. Note that most extra aspects of
tables can be added with extra statements *after* the 'create table'
command has been given, and thus can be completely separate from the
dao-table-definition functionality.

Cheers,
Marijn

On 6/8/08, Rafa? Strzali?ski <nablaone at gmail.com> wrote:
> Hi,
>
>  I'm attaching a  patch that allows to add table extra options ( :check
>  :unique ..) to a DAO definition.
>
>  Sample:
>
>  (defclass account ()
>   ((id :col-type serial )
>    (login :col-type (varchar 255) :accessor login :initarg :login)
>    (password :col-type (varchar 255) :accessor password :initarg :password)
>    (created_at :col-type timestamp :accessor created-at :initform
>  (now-timestamp)))
>   (:unique name)
>   (:metaclass dao-class)
>   (:keys id)
>   (:extra-options (:unique login))
>   (:table-name account.account))
>
>
>
>  --
>  Best regards,
>  Rafal Strzalinski (nabla)
>  http://nablaone.net
>
> _______________________________________________
>  postmodern-devel mailing list
>  postmodern-devel at common-lisp.net
>  http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
>
>
>

From marijnh at gmail.com  Fri Jun 13 03:29:56 2008
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Thu, 12 Jun 2008 20:29:56 -0700
Subject: [postmodern-devel] db-null problem
In-Reply-To: <85147F5E-9422-4EB1-8B41-00B9DB8547DB@budzianowski.net>
References: <85147F5E-9422-4EB1-8B41-00B9DB8547DB@budzianowski.net>
Message-ID: <befaa7aa0806122029t6fdb879bs74ba5d5eb0301de4@mail.gmail.com>

Hey Roman,

Try using pomo:db-null instead!

Cheers,
Marijn


On 6/9/08, Roman Budzianowski <superdog at budzianowski.net> wrote:
> There seems to be a problem with exporting of 'db-null type:
>
>  CL-USER> (pomo:sql (:create-table foo
>         ((age :type (or db-null integer) :default :null))))
>  "CREATE TABLE foo (age OR NOT NULL DEFAULT NULL)"  =========> error!
>
>  CL-USER> (in-package :pomo)
>  #<The POSTMODERN package>
>  POMO> (pomo:sql (:create-table foo
>         ((age :type (or db-null integer) :default :null))))
>  "CREATE TABLE foo (age INTEGER DEFAULT NULL)"
>  POMO>
>
>  Roman
>  _______________________________________________
>  postmodern-devel mailing list
>  postmodern-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
>


From nablaone at gmail.com  Fri Jun 13 18:26:22 2008
From: nablaone at gmail.com (=?UTF-8?Q?Rafa=C5=82_Strzali=C5=84ski?=)
Date: Fri, 13 Jun 2008 20:26:22 +0200
Subject: [postmodern-devel] Table extra options in DAO definition
In-Reply-To: <befaa7aa0806122028l6024a442i5bf8c2c1d3ee66f5@mail.gmail.com>
References: <f1384930806081400v4b2387b3m768374c8efe64dc8@mail.gmail.com>
	<befaa7aa0806122028l6024a442i5bf8c2c1d3ee66f5@mail.gmail.com>
Message-ID: <f1384930806131126y40bea0aag40bf76f166e5127a@mail.gmail.com>

2008/6/13 Marijn Haverbeke <marijnh at gmail.com>:
> Hi Rafal,
>
> Thanks for the patch. I don't have time to look at it right now but
> I'll get back to you in a week or so. Chances are, though, that I
> won't be including it as is.

That's not a problem. I'm using PM on my pet-project, so I can wait for
a "blessed" solution.

> Did you ever use Postmodern before
> version 1.10? The deftable form I had was going in this same
> direction, but it became a mess, so I decided to separate the 'class
> definition' part form the 'table definition' part. A feature similar
> to your patch that I have been thinking about including is to add
> something specifically for adding extra indices, sequences, and
> constraints to a table -- I'm already using something like it in all
> my major postmodern-using projects. Note that most extra aspects of
> tables can be added with extra statements *after* the 'create table'
> command has been given, and thus can be completely separate from the
> dao-table-definition functionality.

I would be fine if these extra aspects can be easy enabled/disabled. Droping
 constraints (FKs, checks, and so on)  is a very common while database
migration.
BTW Have You ever thinking supporting a db migration, from one schema
version to
another one? Something similar to Rails.

Basiclly, I'm not a big fan on keeping all SQL-stuff into an
application code. I like
'create.sql'/'drop.sql' kind of scripts. I'm thinking about PM port of
http://www.cliki.net/clsql-pg-introspect.
Maybe You already have something like that and could share :-)

-- 
Best regards,
Rafal Strzalinski (nabla)
http://nablaone.net


From attila.lendvai at gmail.com  Mon Jun 16 13:57:22 2008
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Mon, 16 Jun 2008 15:57:22 +0200
Subject: [postmodern-devel] the reason why i'd like an iolib network backend
	instead of usocket
Message-ID: <b54b34af0806160657i77684fa5ma78da32980f18626@mail.gmail.com>

dear list,

after some uptime, all of a sudden i was getting these errors on our
server. this is probably something going awry inside sb-bsd-sockets.

as time permits, i'll experiment with an iolib based network backend
for cl-postgres.

- attila


*** At: 2008-06-14T03:47:32.266936+02:00
*** In thread: http worker 34 / serving request /
CALL-WITH-SERVER-ERROR-HANDLER / HANDLE-TOPLEVEL-CONDITION
*** Error:
Socket error in \"socket\": EPROTONOSUPPORT (Protocol not supported)
*** Backtrace is:
000: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0.
SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable argument>
#<ESEHO-PRESENTATION::ESEHO-APPLICATION \"
/\" {911C645}> #<SB-BSD-SOCKETS:PROTOCOL-NOT-SUPPORTED-ERROR {EBE8041}>)
001: ((HU.DWIM.WUI:HANDLE-TOPLEVEL-CONDITION :AROUND (T T))
#<ESEHO-PRESENTATION::ESEHO-APPLICATION \"/\" {911C645}>
#<SB-BSD-SOCKETS:PROTOCOL-NOT-SUPPORTED-ERROR {EBE8041}>)
002: ((FLET HU.DWIM.WUI::HANDLE-REQUEST-ERROR)
#<SB-BSD-SOCKETS:PROTOCOL-NOT-SUPPORTED-ERROR {EBE8041}>)
003: ((LAMBDA (ERROR)) #<SB-BSD-SOCKETS:PROTOCOL-NOT-SUPPORTED-ERROR {EBE8041}>)
004: (SIGNAL #<SB-BSD-SOCKETS:PROTOCOL-NOT-SUPPORTED-ERROR {EBE8041}>)
[:EXTERNAL]
005: (ERROR SB-BSD-SOCKETS:PROTOCOL-NOT-SUPPORTED-ERROR) [:EXTERNAL]
006: (SB-BSD-SOCKETS:SOCKET-ERROR \"socket\")
007: (SB-BSD-SOCKETS:SOCKET-ERROR \"socket\") [:EXTERNAL]
008: ((SHARED-INITIALIZE :AFTER (SB-BSD-SOCKETS:SOCKET T)) #<error
printing object: NIL>) [:EXTERNAL]
009: ((LAMBDA ()))
010: (USOCKET:SOCKET-CONNECT \"database\" 5432) [:EXTERNAL]
011: (CL-POSTGRES::INITIATE-CONNECTION
#<CL-POSTGRES:DATABASE-CONNECTION {107C3F11}>)
012: (CL-POSTGRES:OPEN-DATABASE \"eseho\" \"eseho\" \"szupertitok\"
\"database\" 5432 :NO)
013: ((CL-RDBMS.POSTGRESQL::CONNECTION-OF :AROUND
(CL-RDBMS.POSTGRESQL::POSTGRESQL-POSTMODERN-TRANSACTION))
#<DWIM-META-MODEL::TRANSACTION :begin-executed-p #t {107AB379}>)
0


From marijnh at gmail.com  Thu Jun 19 19:52:36 2008
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Thu, 19 Jun 2008 21:52:36 +0200
Subject: [postmodern-devel] the reason why i'd like an iolib network
	backend instead of usocket
In-Reply-To: <b54b34af0806160657i77684fa5ma78da32980f18626@mail.gmail.com>
References: <b54b34af0806160657i77684fa5ma78da32980f18626@mail.gmail.com>
Message-ID: <befaa7aa0806191252p5967a942m8ebb75cfd8994f0@mail.gmail.com>

Hey Attila,

I've never seen this particular mess, but having low-overhead socket
timeouts would be very useful for most 'serious' projects, and if you
can some up with a patch that doesn't create too much of a chaos in
the codebase, I'd certainly be happy to include it.

Cheers,
Marijn

On Mon, Jun 16, 2008 at 3:57 PM, Attila Lendvai
<attila.lendvai at gmail.com> wrote:
> dear list,
>
> after some uptime, all of a sudden i was getting these errors on our
> server. this is probably something going awry inside sb-bsd-sockets.
>
> as time permits, i'll experiment with an iolib based network backend
> for cl-postgres.
>
> - attila
>
>
> *** At: 2008-06-14T03:47:32.266936+02:00
> *** In thread: http worker 34 / serving request /
> CALL-WITH-SERVER-ERROR-HANDLER / HANDLE-TOPLEVEL-CONDITION
> *** Error:
> Socket error in \"socket\": EPROTONOSUPPORT (Protocol not supported)
> *** Backtrace is:
> 000: ((LAMBDA (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0.
> SB-PCL::.ARG1.)) #<unavailable argument> #<unavailable argument>
> #<ESEHO-PRESENTATION::ESEHO-APPLICATION \"
> /\" {911C645}> #<SB-BSD-SOCKETS:PROTOCOL-NOT-SUPPORTED-ERROR {EBE8041}>)
> 001: ((HU.DWIM.WUI:HANDLE-TOPLEVEL-CONDITION :AROUND (T T))
> #<ESEHO-PRESENTATION::ESEHO-APPLICATION \"/\" {911C645}>
> #<SB-BSD-SOCKETS:PROTOCOL-NOT-SUPPORTED-ERROR {EBE8041}>)
> 002: ((FLET HU.DWIM.WUI::HANDLE-REQUEST-ERROR)
> #<SB-BSD-SOCKETS:PROTOCOL-NOT-SUPPORTED-ERROR {EBE8041}>)
> 003: ((LAMBDA (ERROR)) #<SB-BSD-SOCKETS:PROTOCOL-NOT-SUPPORTED-ERROR {EBE8041}>)
> 004: (SIGNAL #<SB-BSD-SOCKETS:PROTOCOL-NOT-SUPPORTED-ERROR {EBE8041}>)
> [:EXTERNAL]
> 005: (ERROR SB-BSD-SOCKETS:PROTOCOL-NOT-SUPPORTED-ERROR) [:EXTERNAL]
> 006: (SB-BSD-SOCKETS:SOCKET-ERROR \"socket\")
> 007: (SB-BSD-SOCKETS:SOCKET-ERROR \"socket\") [:EXTERNAL]
> 008: ((SHARED-INITIALIZE :AFTER (SB-BSD-SOCKETS:SOCKET T)) #<error
> printing object: NIL>) [:EXTERNAL]
> 009: ((LAMBDA ()))
> 010: (USOCKET:SOCKET-CONNECT \"database\" 5432) [:EXTERNAL]
> 011: (CL-POSTGRES::INITIATE-CONNECTION
> #<CL-POSTGRES:DATABASE-CONNECTION {107C3F11}>)
> 012: (CL-POSTGRES:OPEN-DATABASE \"eseho\" \"eseho\" \"szupertitok\"
> \"database\" 5432 :NO)
> 013: ((CL-RDBMS.POSTGRESQL::CONNECTION-OF :AROUND
> (CL-RDBMS.POSTGRESQL::POSTGRESQL-POSTMODERN-TRANSACTION))
> #<DWIM-META-MODEL::TRANSACTION :begin-executed-p #t {107AB379}>)
> 0
> _______________________________________________
> postmodern-devel mailing list
> postmodern-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
>


From marijnh at gmail.com  Thu Jun 19 22:58:59 2008
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Fri, 20 Jun 2008 00:58:59 +0200
Subject: [postmodern-devel] prepare macro syntax
In-Reply-To: <3883A4C7-F9D2-4515-AEFF-AB7B55019463@budzianowski.net>
References: <AA91DEAC-C7C7-4093-96E5-FA8B30A25286@budzianowski.net>
	<befaa7aa0806071849s197f118ame16459b52fda0842@mail.gmail.com>
	<3883A4C7-F9D2-4515-AEFF-AB7B55019463@budzianowski.net>
Message-ID: <befaa7aa0806191558l7407f0a5t727ec74065585513@mail.gmail.com>

Hi,

The behaviour here was indeed a bit dodgy. I've pushed a patch that
seems to fix this. Take a look.

Regards,
Marijn

On Sun, Jun 8, 2008 at 4:01 AM, Roman Budzianowski
<superdog at budzianowski.net> wrote:
> Right, it threw me off. I assumed that the arg is not evaluated.
> But, then it is... Wrapping it in let and binding the arg makes it work.
>
> On Jun 7, 2008, at 6:49 PM, Marijn Haverbeke wrote:
>
>> Hi Roman,
>>
>> I wouldn't even have expected the first thing to work -- or is the
>> query a string? .. If it is a string, then the second one should
>> probably work too. This behaviour is not intentional in any case. I
>> won't be able to look into it this week, but I'll get back to you.
>>
>> Cheers,
>> Marijn
>>
>>
>> On Sat, Jun 7, 2008 at 10:02 AM, Roman Budzianowski
>> <superdog at budzianowski.net> wrote:
>>>
>>> Hi Marijn,
>>>
>>> (prepare q) where q is bound to a query works fine, however
>>> (prepare (get 'foo 'query)) doesn't complain, but generates incorrect
>>> closure.
>>> Easy workaround, but is this a bug?
>>>
>>> Thanks,
>>>
>>> Roman
>>>
>>> _______________________________________________
>>> postmodern-devel mailing list
>>> postmodern-devel at common-lisp.net
>>> http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
>>>
>> _______________________________________________
>> postmodern-devel mailing list
>> postmodern-devel at common-lisp.net
>> http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
>
> _______________________________________________
> postmodern-devel mailing list
> postmodern-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
>