headers
Robert Marlow | 3 Aug 2004 04:11

Problems with postgresql backend

Hi all

I'm having some issues with the postgresql backend of CLSQL

I've written two servers which access the same database, one enqueueing,
the other dequeueing.

Both servers after a while often come up with one or both of two errors.

Both experience this error from time to time:
WARNING:  there is already a transaction in progress

The enqueuing server also experiences this series of errors:
 message type 0x54 arrived from server while idle
message type 0x44 arrived from server while idle
message type 0x43 arrived from server while idle
message type 0x5a arrived from server while idle
WARNING: Strange result...

The Dequeuing server instead experiences this series of errors (a subset
of the ones the enqueuer experiences):
message type 0x43 arrived from server while idle
message type 0x5a arrived from server while idle

I'm using CL-SQL version 2.11.1-1 from Debian with sbcl-mt
0.8.28+really.0.8.10.48-1 also from Debian (but patched to handle
thread-related reader errors).

Any idea how I can fix this problem?
(Continue reading)

Permalink | Reply | 0 comments |
headers
rm | 10 Aug 2004 20:53
Picon

LIST-CLASSES question

Hello list,

 just something i ran into: according to the documentation the
 LIST-CLASSES is supposed to return a 'list of all the View Classes
 which are connected to DATABASE ...'. 
 In my current setup this only works once i've 'create-view-from-class'ed
 the classes -- since i need to wrap existing relations it seems like
 list-classes will not work for me :-/ Is this intended behavior or just a bug?

 Current software: 
  - clsql  3.0.0-1
  - clsql-postgresql  3.0.0-1
  - sbcl 0.8.21+truly.0.8.13.26-1

 TIA Ralf Mattes
Permalink | Reply | 3 comments |
headers
Marcus Pearce | 11 Aug 2004 00:48
Picon
Favicon

Re: LIST-CLASSES question


>  In my current setup this only works once i've 'create-view-from-class'ed
>  the classes -- since i need to wrap existing relations it seems like
>  list-classes will not work for me :-/ Is this intended behavior or just
>  a bug?

View classes only become associated with a database when they are
'create-view-from-class'ed. Currently in CLSQL, if the database supplied
to LIST-CLASSES is nil or if the supplied root-class is not currently
associated with the supplied database, LIST-CLASSES returns nil.

>From my own reading of the CommonSQL spec, this is the intended behaviour.
However, I am unable to check what CommonSQL actually does in this
situation.

It would seem reasonable to extend this behaviour such that when supplied
with a DATABASE argument of nil, LIST-CLASSES returns a list of those view
classes which are not currently associated with any database (although
this would require an exhaustive search of the subclasses of the supplied
root-class). Thoughts?

Cheers,
Marcus
Permalink | Reply | 2 comments |
headers
Marcus Pearce | 11 Aug 2004 00:57
Picon
Favicon

Re: Escaping SQL strings


> I think defmethod database-output-sql ((str string) database) in
> fdml.lisp requires fixing.  It appears to escape ' and \ as if they were
> being used in CL, by prepending \.  But for sending to SQL, ' needs to
> be escaped by doubling, i.e. '', and \ needs no escaping.

Thanks very much for the bug report, fix and examples. FYI, this has been
fixed in CLSQL 3.0.0.

Cheers,
Marcus
Permalink | Reply | 0 comments |
headers
rm | 11 Aug 2004 01:19
Picon

Re: LIST-CLASSES question

On Tue, Aug 10, 2004 at 11:48:49PM +0100, Marcus Pearce wrote:
> 
> >  In my current setup this only works once i've 'create-view-from-class'ed
> >  the classes -- since i need to wrap existing relations it seems like
> >  list-classes will not work for me :-/ Is this intended behavior or just
> >  a bug?
> 
> View classes only become associated with a database when they are
> 'create-view-from-class'ed. Currently in CLSQL, if the database supplied
> to LIST-CLASSES is nil or if the supplied root-class is not currently
> associated with the supplied database, LIST-CLASSES returns nil.

I see. What is the concept of being "associated" with a database? Is it 
different from just being "connected"? Is using  classes that are _not_ 
'create-view-from-class'ed a bad idea? (Background: this seems to be the
only way to use PostgreSQL's object oriented inheritance feature [1]).

> >From my own reading of the CommonSQL spec, this is the intended behaviour.
> However, I am unable to check what CommonSQL actually does in this
> situation.

Never checked it with UncommonSQL.

> It would seem reasonable to extend this behaviour such that when supplied
> with a DATABASE argument of nil, LIST-CLASSES returns a list of those view
> classes which are not currently associated with any database (although
> this would require an exhaustive search of the subclasses of the supplied
> root-class). Thoughts?

I can live without it, i was more curious about using relations not created
(Continue reading)

Permalink | Reply | 1 comment |
headers
Marcus Pearce | 11 Aug 2004 11:58
Picon
Favicon

Re: LIST-CLASSES question


On Wed, 11 Aug 2004 rm@... wrote:

> I see. What is the concept of being "associated" with a database? Is it
> different from just being "connected"?

Database objects in CLSQL have a slot (accessor database-view-classes)
which stores a list of view classes associated with that database.
Create-view-from-class adds the supplied class to this list for the
supplied database and drop-view-from-class removes it. As a workaround you
could push your view classes onto this list.

> Is using classes that are _not_ 'create-view-from-class'ed a bad idea?
> (Background: this seems to be the only way to use PostgreSQL's object
> oriented inheritance feature [1]).

This is not a bad idea in general - the association of view classes with
database objects is only used in list-classes.

> BTW, how will LIST-CLASSES react after a shutdown of the application or
> in situtations where more than one image needs to access the database?

LIST-CLASSES just returns (database-view-classes database) with those view
classes which are not descended from the supplied ROOT-CLASS or which do
not satisfy the supplied TEST removed, so it shouldn't be affected by
these factors.

> [1] Of course, it would be nice to enhance CLSQL to honor PostgreSQL
> table inheritance -- unfortunately that's not trivial ....
(Continue reading)

Permalink | Reply | 0 comments |
headers
rm | 13 Aug 2004 01:26
Picon

Question about :join slots

Hello list,

I have a  question about slots of the :join type:
Is it possible to create :join slots that use a user-
defined SQL query instead of the list given to db-info?
I have some queries that return lists of objects but are 
rather hard to rewrite into the restricted :home-key / :foreign-key
syntax of CLSQL.

 TIA Ralf Mattes
Permalink | Reply | 11 comments |
headers
Kevin Rosenberg | 13 Aug 2004 01:49
Favicon

Re: Question about :join slots

rm@... wrote:
> I have a  question about slots of the :join type:
> Is it possible to create :join slots that use a user-
> defined SQL query instead of the list given to db-info?
> I have some queries that return lists of objects but are 
> rather hard to rewrite into the restricted :home-key / :foreign-key
> syntax of CLSQL.

No -- not currently. That'd be a worthy extension.

One work-around would be to declare a slot as virtual, then specialize
an around method for slot-value-using-class. You can then set the
value of the slot in that method.

--

-- 
Kevin Rosenberg
kevin@...
Permalink | Reply | 10 comments |
headers
R. Mattes | 13 Aug 2004 13:41
Picon

Re: Question about :join slots

On Fri, 13 Aug 2004 01:49:56 +0200, Kevin Rosenberg wrote:

> rm@... wrote:
>> I have a  question about slots of the :join type: Is it possible to
>> create :join slots that use a user- defined SQL query instead of the
>> list given to db-info? I have some queries that return lists of objects
>> but are rather hard to rewrite into the restricted :home-key /
>> :foreign-key syntax of CLSQL.
> 
> No -- not currently. That'd be a worthy extension.
> 
> One work-around would be to declare a slot as virtual, then specialize
> an around method for slot-value-using-class. You can then set the value
> of the slot in that method.
> 

Thank's a lot for the fast answer to all of my questions. I was affraid i
hat to bite the MOP. Oh well, gives me something to do for my vacations.

Backgound: i'm trying to do an n:m relation/join. My first attempt for
the intermeadiate class was:

(clsql:locally-enable-sql-reader-syntax)

(clsql:def-view-class relations ()
                      ((subject-id :db-kind :key
                                   :type    string
                                   :column  subject_id
                                   :initarg :subject)
(Continue reading)

Permalink | Reply | 9 comments |
headers
R. Mattes | 13 Aug 2004 13:55
Picon

Re: Question about :join slots

On Fri, 13 Aug 2004 13:41:32 +0200, R. Mattes wrote:

>                        (subject    :type :join
>                                    :db-info (:join-class  buch
>                                    :home-key    subject-id
>                                    :foreign-key id
>                                    :retrieval :imediate))

Argh, of course this should be :immediate, but that doesn't make any
change.

 Thanks Ralf
Permalink | Reply | 0 comments |

Gmane