[Sorry for posting it here. I had posted it to usql mailing
list few days ago]
Some questions about UncommonSQL (recent version, two weeks old I
think) if you don't mind.
1. :DB-TYPE
-------------------------------------
Is it possible to use :db-type ? I've tried :db-type "date" but this
turn into 'character varying'.
2. Using [...] syntax ?
-------------------------------------
The following form [foo "bar"]. What it should return ? Initially it
was
"bar" is not of type SYMBOL
after some obvious corrections it become
#<MAISQL-SYS::SQL-IDENT-TABLE FOO bar>
But CommonSQL doc (Xanalys) says (14.5.1.1) it should be
[foo "bar"] =>#<SQL-IDENT FOO \"bar\">
Here is some other examples from 14.5.1.1. [...] form is the first,
then following the '=>' the result according to 14.5.1.1 and last what
I actually see in CMUCL.
["foo" bar] =>#<SQL-IDENT "\"foo\".BAR">
Type-error in KERNEL::OBJECT-NOT-SYMBOL-ERROR-HANDLER:
"foo" is not of type SYMBOL
--
[foo :integer] =>#<SQL-IDENT "FOO" :INTEGER>
#<MAISQL-SYS::SQL-IDENT-ATTRIBUTE NIL.FOO INTEGER>
--
["foo" bar :integer] -->#<SQL-IDENT "\"foo\".BAR" :INTEGER>
Type-error in KERNEL::OBJECT-NOT-SYMBOL-ERROR-HANDLER:
"foo" is not of type SYMBOL
Could you give me the idea of [...] in UncommonSQL ? I'm rather
confused.
3. Using :DB-WRITER, :DB-READER
-------------------------------------
How I should specify the argument to :db-writer, :db-reader slot
option ? I've tried #'my-function and #'(lambda ...) but this doesn't
work.
Thanks in advance
--
Vladimir Zolotykh
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> 1. :DB-TYPE
> -------------------------------------
>
> Is it possible to use :db-type ? I've tried :db-type "date" but this
> turn into 'character varying'.
In that case you also need to tell USQL what database type to use
using the sql-sys::database-get-type-sepcifier method, and then you
need to tell it how to read and write those values. Howver, for
storing data/times I suggest you checkout out the lcoal-time-db and
local-time packages from the same location as USQL. They provide a
way for storing times and durations in the DB.
> Here is some other examples from 14.5.1.1. [...] form is the first,
> then following the '=>' the result according to 14.5.1.1 and last what
> I actually see in CMUCL.
>
> ["foo" bar] =>#<SQL-IDENT "\"foo\".BAR">
>
> Type-error in KERNEL::OBJECT-NOT-SYMBOL-ERROR-HANDLER:
> "foo" is not of type SYMBOL
The USQL macro doesn't appear to support table aliases, since we
developers never use them. I started fixing it but won't be able to
get it all done today. I will commit my fixes as I go along.
> 3. Using :DB-WRITER, :DB-READER
> -------------------------------------
>
> How I should specify the argument to :db-writer, :db-reader slot
> option ? I've tried #'my-function and #'(lambda ...) but this doesn't
> work.
Sadly, :db-writer and :db-reader and not presently supported. Since
it appears you are trying to store dates in the DB, I suggest you
check out the packages I mentioned above since they already provide
that service. I could provide you with some guidance on getting
:db-writer and :db-reader working, but it's somewhat non-trivial if I
recall correctly.
--
Craig Brozefsky <·····@onshored.com> Senior Programmer
onShore Development http://www.onshore-devel.com
Free Common Lisp Software http://alpha.onshored.com/lisp-software
Craig Brozefsky wrote:
>
> In that case you also need to tell USQL what database type to use
> using the sql-sys::database-get-type-sepcifier method, and then you
> need to tell it how to read and write those values.
This is rather cryptic for me now. Should I modify sources ?
Could you be more plain ? Could you point me to functions or
methods I should learn to be able to implement this ?
> Howver, for
> storing data/times I suggest you checkout out the lcoal-time-db and
> local-time packages from the same location as USQL. They provide a
> way for storing times and durations in the DB.
Should I specify slot type as integer in that case ?
If so, dates will be stored as integers in database table. Dealing
with such dates in SQL is rather inconvenient I think. I've found
myself doing such operations very frequently (SQL level I mean) to
just ignore that.
>
> [snip]. I could provide you with some guidance on getting
> :db-writer and :db-reader working, but it's somewhat non-trivial if I
> recall correctly.
Please do so. I'll try to do it if I could.
--
Vladimir Zolotykh
* Vladimir Zolotykh <······@eurocom.od.ua>:
>> using the sql-sys::database-get-type-sepcifier method, and then you
>> need to tell it how to read and write those values.
> This is rather cryptic for me now. Should I modify sources ?
No, just define methods specializing on the type you want. You could
always add them in the usql-sources, but you don't have to.
;; Something like this. (And have a look at usql-sources, too.)
(in-package :maisql-sys)
(defmethod database-get-type-specifier ((type (eql 'signed-byte))
args database)
(declare (ignore database))
(if args
(cond ((> (car args) 32)
"INT8")
((> (car args) 16)
"INT4")
(t
"INT2"))
"INTEGER"))
--
johs
Vladimir Zolotykh <······@eurocom.od.ua> writes:
> Craig Brozefsky wrote:
>
> >
> > In that case you also need to tell USQL what database type to use
> > using the sql-sys::database-get-type-sepcifier method, and then you
> > need to tell it how to read and write those values.
>
> This is rather cryptic for me now. Should I modify sources ?
> Could you be more plain ? Could you point me to functions or
> methods I should learn to be able to implement this ?
You would be defining new methods which specialize on the name of the
type you are using and/or the database backend you want to support.
There is really no better explanation available at this time than the
local-time/database-funcs.lisp file in the onShore local-time package.
You can see there which methods need to be defined in order to support
a new slot type.
> > Howver, for
> > storing data/times I suggest you checkout out the lcoal-time-db and
> > local-time packages from the same location as USQL. They provide a
> > way for storing times and durations in the DB.
>
> Should I specify slot type as integer in that case ?
No, use local-time and the values will be stored as DATETIME values in
the database. durations are indeed stored as INT8.
--
Sincerely,
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig