postmodern-devel

postmodern-devel@common-lisp.net

252 discussions

[postmodern-devel] sql-op :raw
by Roman Budzianowski 06 Jun '08

06 Jun '08

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

2 1

[postmodern-devel] dao functionality
by Roman Budzianowski 05 Jun '08

05 Jun '08

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

2 1

[postmodern-devel] Guarding against DB-NULL from other packages in :CREATE-TABLE
by J.P. Larocque 10 May '08

10 May '08

Hi, I'm defining tables with Postmodern and made the mistake of specifying a column type such as (OR TEXT DB-NULL), where DB-NULL was a symbol newly interned into my current package rather than the symbol in the S-SQL package. This resulted in SQL expressions with illegal syntax being generated (e.g. "column_name OR NOT NULL"). After tracking down the problem and finding it was my fault, I made changes (attached) to catch column-type errors earlier. The patch signals an error in DEF-SQL-OP :CREATE-TABLE when a column type is a list which begins with OR and does not meet the other original criteria for an or-db-null type: DB-NULL is a member, and length is 3. It also now ensures that DB-NULL doesn't occur twice, or on its own, outside of an OR compound type. I didn't do anything to validate other "compound" types such as NUMERIC. You might find it a bit odd that I format the DB-NULL symbol in my ERROR calls with ~S in the format control string instead of simply putting "DB-NULL" in the string: (error "Illegal compound type for column: ~S~ ~&(Only (~S x ~S) and (~S ~S x) are allowed.)" type 'or 'db-null 'or 'db-null)) This ensures that the S-SQL package name is prefixed to the symbol name--but only if S-SQL was not imported by the current package. This emphasizes to these users that DB-NULL was not imported into their current package and this is probably what their problem is. For instance: Illegal compound type for column: (OR TEXT DB-NULL) (Only (OR x S-SQL) and (OR S-SQL x) are allowed.) [Condition of type SIMPLE-ERROR] -- J.P. Larocque: <jpl(a)thoughtcrime.us>, +1 509 324-2410

2 1

[postmodern-devel] Release 1.12
by Marijn Haverbeke 30 Apr '08

30 Apr '08

Hi list, There is now a version 1.12 of postmodern. It features SSL support, a few rather un-spectacular new features, and less bugs than 1.11. See the docs and the darcsweb for details. Regards, Marijn

1 0

[postmodern-devel] Error when no persistent field
by Sven Van Caekenberghe 21 Apr '08

21 Apr '08

Hi, I defined an object with metaclass dao-class but forgot to add any col- type options, this results in a rather cryptic error that is hard to get out of in LispWorks: P1 10 > (select-dao 'enumeration) Error: The assertion (= (LENGTH POSTMODERN::QUERY-FIELDS) POSTMODERN::N-DAO-FIELDS) failed. 1 (continue) Retry assertion. 2 (abort) Return to level 0. 3 Return to top loop level 0. Type :b for backtrace, :c <option number> to proceed, or :? for other options P1 11 : 1 > :bq (HARLEQUIN-COMMON-LISP:SUBFUNCTION 1 POSTMODERN::BUILD-ROW-READER) <- CL-POSTGRES::SEND-QUERY <- (HARLEQUIN-COMMON-LISP:SUBFUNCTION (LABELS #:G244377) CL- POSTGRES:EXEC-QUERY) <- CL-POSTGRES:EXEC-QUERY <- LET <- EVAL <- CAPI::CAPI-TOP-LEVEL-FUNCTION <- CAPI::INTERACTIVE-PANE-TOP- LOOP <- (HARLEQUIN-COMMON-LISP:SUBFUNCTION MP::PROCESS-SG-FUNCTION MP::INITIALIZE-PROCESS-STACK) I can live with this, but maybe it would be good to make this more user friendly. Cheers, Sven

2 4

[postmodern-devel] Timestamp (with time zone)
by Sven Van Caekenberghe 14 Apr '08

14 Apr '08

Hi, This is partly postmodern, partly postgresql related. I was wondering whether it would not be useful to also do the following when loading simple-date above postmodern: (in-package :simple-date) (cl-postgres:set-sql-datetime-readers :timestamp-with-timezone (lambda (usecs) (multiple-value-bind (days usecs) (floor usecs +usecs-in-one-day+) (make-instance 'timestamp :days (+ days +postgres-day-offset+) :ms (floor usecs 1000))))) Or even in place of the normal :timestamp binding (from which the above code is copied) ? From my experiments and reading, using timestamp with time zone as SQL type is more useful than timestamp. What I want is a created or last-modified timestamp that is set or updated automatically by SQL and not CL with a default like now(). The problem seems to be that the way now() is interpreted is dependent on the time zone set for the session (or the time zone default of postgresql, which defaults to your machine's). The only correct thing to store are GMT timestamps and to adjust those to the viewer's own time zone. psql does that correctly only with the type timestamp with time zone and not with the type timestamp, although they seem to be the same thing internally. In CL, (simple-date:universal-time-to-timestamp (get-universal-time)) is always GMT, indepedent of the current (viewer's) timezone. In PG SQL this seems to be hard to do using now() or similar functions. So out of the box reader support for that type would be useful. A second question is how to correctly specify this col-type in a DAO since :timestamp-with-time-zone doesn't generate the necessary spaces when generating the table definition and a string is not considered a CL type ? Any thoughts ? Thanks, Sven

2 2

[postmodern-devel] s-sql insert-into problem
by Jens Teich 14 Apr '08

14 Apr '08

I have a tablename as string, a list of fieldnames as strings and a list of values known only at runtime all. Tried the following. What is going wrong? HB> (sql (append (list :insert-into (intern "table") :set) (loop for k in '("field1" "field2" "field3") for v in '(4 5 6) append (list (intern k) v)))) Error: Value (:INSERT-INTO |table| :SET |field1| 4 |field2| 5 |field3| 6) can not be converted to an SQL literal. [Condition of type SIMPLE-ERROR] Jens

2 2

[postmodern-devel] Release 1.11 [was: Unexpected Result from SET command]
by Marijn Haverbeke 09 Apr '08

09 Apr '08

Hey list, I've just released version 1.11 of Postmodern. Mostly bug-fixes, but one feature to be careful with is the new auto-escaping: If you were using 'true and 'false in your queries for boolean values, they will now be escaped and not be read as boolean values at all, so use T and NIL instead. See http://common-lisp.net/project/postmodern for a slightly more detailed release description and, as always, the darcsweb for the definite word on what happened. Regards, Marijn On Tue, Apr 1, 2008 at 5:13 PM, Sven Van Caekenberghe <scaekenberghe(a)common-lisp.net> wrote: > Marijn, > > > > On 01 Apr 2008, at 15:47, Marijn Haverbeke wrote: > > > > Hey Sven, > > > > > > > POSTMODERN 45 > (execute "set time zone gmt") > > > CL-POSTGRES: set time zone gmt > > > Error: Postgresql protocol error: Unexpected message received: S > > > > > > > Oops - this was a case in the pg client/server protocol that I was not > > handling correctly. I've pushed a patch which should solve the > > problem. > > > > Cheers, > > Marijn > > > > Pulling from > "http://common-lisp.net/project/postmodern/darcs/postmodern"... > > Tue Apr 1 15:39:53 CEST 2008 marijnh(a)gmail.com > * handle ParameterStatus messages when reading in query results > > And it works for me now! Thanks a lot for the fast response. > > Regards, > > > > Sven > > > _______________________________________________ > postmodern-devel mailing list > postmodern-devel(a)common-lisp.net > http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel >

1 0

[postmodern-devel] Unexpected Result from SET command
by Sven Van Caekenberghe 01 Apr '08

01 Apr '08

Hi, Is it possible that there is something wrong or missing in handling the result from a SET command ? POSTMODERN 44 > (connect-toplevel "test" "postgres" "" "localhost") POSTMODERN 45 > (execute "set time zone gmt") CL-POSTGRES: set time zone gmt Error: Postgresql protocol error: Unexpected message received: S 1 (abort) Return to level 0. 2 Return to top loop level 0. Type :b for backtrace, :c <option number> to proceed, or :? for other options POSTMODERN 46 : 1 > :b Call to CL-POSTGRES::LOOK-FOR-ROW Call to CL-POSTGRES::SEND-QUERY Call to (HARLEQUIN-COMMON-LISP:SUBFUNCTION (LABELS #:G135637) EXEC- QUERY) Call to EXEC-QUERY Call to EVAL Call to CAPI::CAPI-TOP-LEVEL-FUNCTION Call to CAPI::INTERACTIVE-PANE-TOP-LOOP Call to (HARLEQUIN-COMMON-LISP:SUBFUNCTION MP::PROCESS-SG-FUNCTION MP::INITIALIZE-PROCESS-STACK) Thanks, Sven

2 2

[postmodern-devel] dao and *escape-sql-names-p*
by Gavin Scott 30 Mar '08

30 Mar '08

Hello, It appears that setting *escape-sql-names-p* breaks dao objects a bit. If it is t when defclass is called, calling get-dao on that class will result in an error from build-row-reader like "Field field does not exist in table class TABLE-CLASS", even though field does indeed exist. This is because slot-sql-name will return a quoted copy of the field name due to *escape-sql-names-p*. A fix is to change direct-column-slot's shared-initialize method to use s-sql:make-sql-name rather than to-sql-name; make-sql-name doesn't quote the column name. However, make-sql-name would then need to be exported by s-sql. A somewhat related issue is that the dao documentation example: http://common-lisp.net/project/postmodern/postmodern.html#daos (defclass user () ... ) has problems if *escape-sql-names-p* is not set since user is an sql keyword. I personally would prefer to see *escape-sql-names-p* set as the default, which would fix this issue. Another solution would be to pick a different example class name or to set *escape-sql-names-p*. Thanks, Gavin Scott gavindscott(a)gmail.com

2 2

← Newer
1
...
16
17
18
19
20
21
22
...
26
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

postmodern-devel