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: INS
> 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
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?
>
> 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?
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
> 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?
___
pos
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 cancel
> 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
t
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.
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 topl
> 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
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
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@comm
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 w
14 matches
Mail list logo
