From airbaggins at gmail.com Mon Jan 14 08:59:29 2008 From: airbaggins at gmail.com (William Robinson) Date: Mon, 14 Jan 2008 08:59:29 +0000 Subject: [submarine-devel] connection-spec requiring constant values... In-Reply-To: References: Message-ID: <478B2471.8000007@gmail.com> Hi Is there some way to make connection spec take in variables instead of just literal strings and whatnot? Ideally giving a *connection-spec* special would be good, or even constant +db-user+, +db-pass+ etc. Thanks bill From airbaggins at gmail.com Tue Jan 15 09:50:48 2008 From: airbaggins at gmail.com (William Robinson) Date: Tue, 15 Jan 2008 09:50:48 +0000 Subject: [submarine-devel] connection-spec requiring constant values... In-Reply-To: <19e19e410801141657u180c4c47ic4fbe002128e7007@mail.gmail.com> References: <478B2471.8000007@gmail.com> <19e19e410801141657u180c4c47ic4fbe002128e7007@mail.gmail.com> Message-ID: <478C81F8.4090904@gmail.com> Ryszard Szopa wrote: >> Is there some way to make connection spec take in variables instead of >> just literal strings and whatnot? >> >> Ideally giving a *connection-spec* special would be good, or even >> constant +db-user+, +db-pass+ etc. >> > > How about > > (defparameter *db* "submarine-test") > (defparameter *db-user* "richard") > (defparameter *db-password* "dupa55") > (defparameter *db-host* "localhost") > > (defdao foobar () > ((baz :type string :initarg :baz :accessor baz-of)) > (:connection-spec *db* *db-user* *db-password* *db-host*)) > ? > > (I am sorry, but I can't test if it works right now.) > > In my code I usually define a macro `dao' which expands to a dao > definition w/ the right connection spec. In principle, every dao class > could connect to a different db (though foreign keys might cause some > trouble if you try it), and a dao w/o a connection spec doesn't get > any db counterpart -- it is just for inheritance, etc. However, using > multiple db-s doesn't look like the most useful feature in the world, > so I may consider using a *db-spec* variable as you suggest. > > If I get some free time tomorrow I will take a look if there can be an > easy workaround for your problem. > > Hi, yeah, I did try the specials like that, but the macro doesn't expand, complaining about the wrong type. It seems to really want literals. I think it should be a small change to make it work, unfortunately, i don't know MOP at all, so I couldn't say. It's an admirable project though. It looks a lot cleaner. Have you thought at all about supporting PostgreSQL's table multiple-inheritance? I can't imagine that it would be amazingly difficult as I should think that CLOS could map fairly cleanly onto it. I have pretty much switched back to using plain S-SQL for now. Thanks bill