Hi!
When developing with postmodern I'm having two problems:
If a query is wrong, my slime connection seems to get disconnected or waiting for something (I have to hit C-c c to get the REPL back). Besides, when an error ocurrs, I don't get notified immediatly, but after I make another query, in which case I get a "the database is processing another query" (the screwed up query). So I have to restart the connection or the application (I'm developing a Web application)... :(
Do someone else have the same problems? How do you fix them?
Thanks!
Mariano
Hello Mariano,
I haven't seen this issue before. Are those queries made from the REPL, or from another thread? Also, which CL implementation, and which Postgres version are you using?
Best, Marijn
I get this sometimes when I have done a "wrong" query that is wrong in that it would take a very long time to complete, not a malformed SQL statement.
Then I interrupt the process from the lisp/slime side, but the PostgreSQL side is still happily executing. The toplevel connection is still waiting for the result, and hence you have to reconnect toplevel (or better, kill the rogue postgres process).
This behaviour seems correct to me, or at least suitable enough. A minor improvement might be to kill the query if you interrupt and cancel the lisp-side process, but that sounds like too much trouble.
So it depends how "wrong" wrong is.
-Luke
On Sat, Mar 20, 2010 at 9:17 AM, Marijn Haverbeke marijnh@gmail.com wrote:
Hello Mariano,
I haven't seen this issue before. Are those queries made from the REPL, or from another thread? Also, which CL implementation, and which Postgres version are you using?
Best, Marijn
postmodern-devel mailing list postmodern-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
This behaviour seems correct to me, or at least suitable enough. A minor improvement might be to kill the query if you interrupt and cancel the lisp-side process, but that sounds like too much trouble.
I think there actually is unwinding code that tries to do this, but apparently it doesn't work. I'll make a note for myself to test that again sometime.
Lucas Hope escribió:
I get this sometimes when I have done a "wrong" query that is wrong in that it would take a very long time to complete, not a malformed SQL statement.
Then I interrupt the process from the lisp/slime side, but the PostgreSQL side is still happily executing. The toplevel connection is still waiting for the result, and hence you have to reconnect toplevel (or better, kill the rogue postgres process).
This behaviour seems correct to me, or at least suitable enough. A minor improvement might be to kill the query if you interrupt and cancel the lisp-side process, but that sounds like too much trouble.
So it depends how "wrong" wrong is.
Mmm...maybe that's what is happening. I'll check. Thanks
Mariano
Marijn Haverbeke escribió:
Hello Mariano,
I haven't seen this issue before. Are those queries made from the REPL, or from another thread? Also, which CL implementation, and which Postgres version are you using?
I'm using SBCL and the repo version of postmodern with postgresql 8.3.8. The queries are made from the web app. I guess it may have to do with what Lucas says. I'll be back after doing some tests and having a clearer idea of what may be happening. Thanks
Mariano
I think there actually is unwinding code that tries to do this, but apparently it doesn't work. I'll make a note for myself to test that again sometime.
This is currently not implemented, I found out. I also remembered why -- the protocol for canceling requests is rather cumbersome, and at the time I didn't feel it was important enough to implement. See http://www.postgresql.org/docs/current/static/protocol-flow.html#AEN80105 for the details.
Marijn Haverbeke escribió:
I think there actually is unwinding code that tries to do this, but apparently it doesn't work. I'll make a note for myself to test that again sometime.
This is currently not implemented, I found out. I also remembered why -- the protocol for canceling requests is rather cumbersome, and at the time I didn't feel it was important enough to implement. See http://www.postgresql.org/docs/current/static/protocol-flow.html#AEN80105 for the details.
So, I have no way of telling postgres to stop processing the query? Actually, what I have are unsynchronized DAO objects (no any sort of long queries), so postmodern complains, but when that happens, the database hangs and I cannot query it again after I have fixed the object-table synchronization.
Mariano
Marijn Haverbeke escribió:
So, I have no way of telling postgres to stop processing the query? Actually, what I have are unsynchronized DAO objects (no any sort of long queries),
Can you show some code that demonstrates what you mean by an unsynchronized DAO object?
When you have an CLOS (DAO) object's attribute and it doesn't exist in the database table. Or otherwise, when you have an attribute in the table that is not defined in the DAO class. I think you get a DAO synchronization error when any of those happen. That is fine with me, but I would like to get rid of the hung up and be able to go on querying the db.
For example:
(defclass project-activity () ((userid :accessor userid :initarg :userid :initform 0 :col-type integer :documentation "The id of the user we are registering the activity for") (projectid :accessor projectid :initarg :projectid :initform 0 :col-type integer :documentation "The id of the project in which activity was detected") (value :accessor value :initarg :value :initform 0 :col-type integer :documentation "Each time user's activity in the project is detected, this value is incremented. This is used to determine the most active projects")) (:metaclass dao-class) (:documentation "Instances of this class are created when an user modifies aproject (i.e. creates, modifies, or comments one of its issues)"))
If any of the attributes is not in the database, for instance 'value', then I get the error and have to restart my application.
Marijn Haverbeke escribió:
If any of the attributes is not in the database, for instance 'value', then I get the error and have to restart my application.
Still not very clear -- how can the value not be in the database? You mean it is null for the record you are retrieving?
No. The column 'value' is not in the table. The database schema does not match the class definition.
I have some of this kind of errors because I'm porting an application from clsql to postmodern and clsql didn't check that the database and the code matched (at least not as strongly as postmodern), and I have some cases in which the data doesn't match the code.
Anyway, I'm not sure the problem arises only when a DAO synchronization error ocurrs, but I have to do more tests to tell you that.
No. The column 'value' is not in the table. The database schema does not match the class definition.
Ah, now I get it. Still, creating a situation like that, I immediately get this error:
Database error 42703: column "y" does not exist Query: INSERT INTO foo (x, y) VALUES (1, 2) [Condition of type cl-postgres-error:syntax-error-or-access-violation]
... and the connection is fine.
So, if you want me to look into this, a script that isolates the issue and can be ran against an empty database to produce the error would probably help.
Cheers, Marijn
Marijn Haverbeke escribió:
No. The column 'value' is not in the table. The database schema does not match the class definition.
Ah, now I get it. Still, creating a situation like that, I immediately get this error:
Database error 42703: column "y" does not exist Query: INSERT INTO foo (x, y) VALUES (1, 2) [Condition of type cl-postgres-error:syntax-error-or-access-violation]
... and the connection is fine.
So, if you want me to look into this, a script that isolates the issue and can be ran against an empty database to produce the error would probably help.
Ok, so maybe it is a problem in my setup. I'll be back with a script like you say if things get to difficult to put up with. I can go on developing the application for the moment.
Thanks for your help.
Mariano
postmodern-devel@common-lisp.net
-
Lucas Hope -
Mariano Montone -
Marijn Haverbeke