From tsufiev at gmail.com  Mon Feb  2 10:31:41 2009
From: tsufiev at gmail.com (Timur Sufiev)
Date: Mon, 2 Feb 2009 13:31:41 +0300
Subject: [postmodern-devel] timestamps return format
Message-ID: <289a24fb0902020231m4f79f46ahb3373281d00996fd@mail.gmail.com>

Hi!

In order to convert timestamps from unix time to GMT strings I used
the following select query:
SELECT TIMESTAMP 'epoch' + 1195374767 * INTERVAL '1 second'
or, the s-sql analogue
`(:select (:+ (:type "epoch" timestamp)
                       (:* ,unix-time (:type "1 second" interval))))
Surprisignly, it returned timestamps as numbers, not strings. After
some investigation the reason of that behaviour became clear. Consider
2 following queries.

(pomo:query (:select 'timestamp :from 'sales :where (:and (:=
'vend-machine-id 2) (:< 'timestamp "2009-01-12"))))
(("2009-01-11 18:37:18+03") ("2009-01-11 23:59:59+03") ("2009-01-11
23:59:59+03") ("2009-01-11 23:59:59+03") ("2009-01-11 23:59:59+03")
("2009-01-11 23:59:59+03"))

(pomo:query (:select (:type 'timestamp timestamp) :from 'sales :where
(:and (:= 'vend-machine-id 2) (:< 'timestamp "2009-01-12"))))
((3440687838) (3440707199) (3440707199) (3440707199) (3440707199) (3440707199))

So, type-cast to TIMESTAMP makes postmodern to return timestamps as
numbers. How is it possible to return unix-time as GMT strings via
postmodern sql queries?

-- 
Timur Sufiev



From marijnh at gmail.com  Mon Feb  2 11:16:43 2009
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Mon, 2 Feb 2009 12:16:43 +0100
Subject: [postmodern-devel] timestamps return format
In-Reply-To: <289a24fb0902020231m4f79f46ahb3373281d00996fd@mail.gmail.com>
References: <289a24fb0902020231m4f79f46ahb3373281d00996fd@mail.gmail.com>
Message-ID: <befaa7aa0902020316n40f043c6ndcad99a7ba95e2b7@mail.gmail.com>

I think (remhash 1114 cl-postgres:*sql-readtable*) is what you want --
where 1114 is the OID of the timestamp type. Cl-postgres registers a
binary interpreter for that type by default, since that makes it
easier to stuff these values into custom datatypes (see
set-sql-datetime-readers). Unregistering that interpreter-function
will make it retrieve the values as strings.

Best,
Marijn



From tsufiev at gmail.com  Mon Feb  2 11:29:38 2009
From: tsufiev at gmail.com (Timur Sufiev)
Date: Mon, 2 Feb 2009 14:29:38 +0300
Subject: [postmodern-devel] timestamps return format
In-Reply-To: <befaa7aa0902020316n40f043c6ndcad99a7ba95e2b7@mail.gmail.com>
References: <289a24fb0902020231m4f79f46ahb3373281d00996fd@mail.gmail.com>
	<befaa7aa0902020316n40f043c6ndcad99a7ba95e2b7@mail.gmail.com>
Message-ID: <289a24fb0902020329l67b32805sfeae6c0060e91821@mail.gmail.com>

Thanks, it works!

2009/2/2 Marijn Haverbeke <marijnh at gmail.com>:
> I think (remhash 1114 cl-postgres:*sql-readtable*) is what you want --
> where 1114 is the OID of the timestamp type. Cl-postgres registers a
> binary interpreter for that type by default, since that makes it
> easier to stuff these values into custom datatypes (see
> set-sql-datetime-readers). Unregistering that interpreter-function
> will make it retrieve the values as strings.
>
> Best,
> Marijn
>
> _______________________________________________
> postmodern-devel mailing list
> postmodern-devel at common-lisp.net
> http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
>



-- 
Timur Sufiev



From attila.lendvai at gmail.com  Fri Feb  6 16:13:12 2009
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Fri, 6 Feb 2009 17:13:12 +0100
Subject: [postmodern-devel] *silently-truncate-ratios*
Message-ID: <b54b34af0902060813m770543k2f200c6901116210@mail.gmail.com>

> Thanks for the patch. I've revised the writer function a bit -- there
> was some useless cruft in it, and you misspelled floating as foating
> -- and added a switch to turn off the raising of errors,


thanks for the cleanup, it was just a quick'n'dirty result of a longer
debugging session...


> *silently-truncate-literals*, which defaults to T, since I suspect not
> everyone is happy with errors like that popping up. You can set it to
> NIL and get the behaviour you're after.


...but i really don't like the default of that special.

rationale: 1) you start using the lib, do some calculations involving
db storage, some time later realize that they are somewhat off, start
digging where the hell it goes wrong, waste a lot of time looking at
too many things until you finally realize that 7/10 written to the
database silently comes back as something else than 7/10.

imho, that special should default to NIL for the least surprises and
for bringing the symptoms of the error *much* closer to their cause.

then: 2) user stars using lib, stores ratios in db, at some point
faces a descriptive error message which includes a hint about the
above mentioned special, reads up on the issue if necessary, based on
necessary understanding of the issue decides to add required coercions
to his code or to set/bind the special to T.

summing up all the time people would spend with the use-case 1) is a
lot more than people would spend with 2).

now, i don't care much, because i've been through 1) already... :) but
i suggest these changes for everyone's good.

i've pushed what i think to my repo, but i will not stick to it. if
you decide to keep things as they are, i'll eventually unpull my patch
to enjoy the benefit of the zero distance from the official repo.

hth,

-- 
 attila

ps: i've cc'd the list if other lib users want to speak up on the issue...



From marijnh at gmail.com  Fri Feb  6 18:57:25 2009
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Fri, 6 Feb 2009 19:57:25 +0100
Subject: [postmodern-devel] *silently-truncate-ratios*
In-Reply-To: <b54b34af0902060813m770543k2f200c6901116210@mail.gmail.com>
References: <b54b34af0902060813m770543k2f200c6901116210@mail.gmail.com>
Message-ID: <befaa7aa0902061057m10e7934dy4075fd9c5cf74a1d@mail.gmail.com>

> rationale: 1) you start using the lib, do some calculations involving
> db storage, some time later realize that they are somewhat off, start
> digging where the hell it goes wrong, waste a lot of time looking at
> too many things until you finally realize that 7/10 written to the
> database silently comes back as something else than 7/10.

But.... 7/10 will be written as 0.7 just fine. Of course, this holds
for 1/3, but there's no way to do that right, so in effect we'd be
disallowing the writing of rationals to the db (except in cases where
the divisor is guaranteed to be something like 10 or 4).

> then: 2) user stars using lib, stores ratios in db, at some point
> faces a descriptive error message which includes a hint about the
> above mentioned special, reads up on the issue if necessary, based on
> necessary understanding of the issue decides to add required coercions
> to his code or to set/bind the special to T.

Well, what I'm afraid of is 3) the user has been happily running a
system on top of CL-Postgres, upgrades, and suddenly finds his system
crashing. That's a bad thing, no?

Cheers,
Marijn



From attila.lendvai at gmail.com  Fri Feb  6 19:29:29 2009
From: attila.lendvai at gmail.com (Attila Lendvai)
Date: Fri, 6 Feb 2009 20:29:29 +0100
Subject: [postmodern-devel] *silently-truncate-ratios*
In-Reply-To: <befaa7aa0902061057m10e7934dy4075fd9c5cf74a1d@mail.gmail.com>
References: <b54b34af0902060813m770543k2f200c6901116210@mail.gmail.com>
	<befaa7aa0902061057m10e7934dy4075fd9c5cf74a1d@mail.gmail.com>
Message-ID: <b54b34af0902061129k65d4fbe3od400c06b1fba3a16@mail.gmail.com>

> But.... 7/10 will be written as 0.7 just fine. Of course, this holds
> for 1/3, but there's no way to do that right, so in effect we'd be
> disallowing the writing of rationals to the db (except in cases where
> the divisor is guaranteed to be something like 10 or 4).


yes, by default disallowing the writing of ratios to the db on which a
store/load operation is not an #'identity. (btw, cl-perec enforces
this philosophy on an even more fine-grained level for all the data
types (or at least it should). it has the actual type information of
the receiving column, not just the type of the value that is to be
written, and errors *at storing* if the value is going to be distorted
by the db).

which is along the line with my thinking: by default report
potentially surprising behavior as early as possible (but leave some
ways to acknowledge the issue, once the decision has been made). iow,
fail early.


> Well, what I'm afraid of is 3) the user has been happily running a
> system on top of CL-Postgres, upgrades, and suddenly finds his system
> crashing. That's a bad thing, no?


not in my world. i know i'm radical with this way of thinking, but if
user (who is a programmer here!) is not ready for an upgrade, then
they simply shouldn't upgrade. i have countless repos subscribed in my
feed reader, so i get notified of the changes even before pulling
them. incompatible changes are inevitable and DVCS' make it as easy to
deal with them as never before. i had some patches even in postmodern
itself that i didn't pull to the live system for quite a while.

and what you call "crashing" in my reading means that after the
upgrade running the test suite stops with a descriptive error message,
even showing the context... now, if people have no test suites at all,
then no form of backward compatibility can save them.

this kind of "crashing" is a lot much better than getting a mail half
a year later, which, after a few days investigation, leads to the
realization that your government transferred the wrong amount of money
to 3200 municipalities for half a year... :)

it didn't happen, because we catch it in the test phase of a new
project (or we didn't get that mail yet... :) but still, you get the
point.

anyways, this is just one opinion, but i hope gives some insight why i
argue for this behavior.

-- 
 attila



From zaries at global.co.za  Fri Feb 27 06:47:56 2009
From: zaries at global.co.za (Phil Marneweck)
Date: Fri, 27 Feb 2009 08:47:56 +0200
Subject: [postmodern-devel] Get keys out of dao-class
Message-ID: <1235717276.13095.5.camel@scatha>

Hi 

How would one find out what the keys are on a dao-class?

I have scratched around in the code and found dao-column-fields, but the
equavilant for keys seems to be dao-keys but I cant find a defun for
it...I am not even sure it should have a defun.

Regards
Phil




From marijnh at gmail.com  Fri Feb 27 07:37:41 2009
From: marijnh at gmail.com (Marijn Haverbeke)
Date: Fri, 27 Feb 2009 08:37:41 +0100
Subject: [postmodern-devel] Get keys out of dao-class
In-Reply-To: <1235717276.13095.5.camel@scatha>
References: <1235717276.13095.5.camel@scatha>
Message-ID: <befaa7aa0902262337o50dbac77r93a706952db2fae5@mail.gmail.com>

Doesn't dao-keys work? There's no defun for it since it's a method.
Call it on a class to get the slot names, on an instance to get the
slot values.

Best,
Marijn



From zaries at global.co.za  Fri Feb 27 08:38:18 2009
From: zaries at global.co.za (Phil Marneweck)
Date: Fri, 27 Feb 2009 10:38:18 +0200
Subject: [postmodern-devel] Get keys out of dao-class
Message-ID: <MWS38def785d6ae884163a2c558dba0102617@mws38>

Thanx, I never thought about it being a method. I have not tried it yet, I was interested in seeing how it works, that is why I was scratching in the code.



?----- Original Message ------
?From:Marijn Haverbeke
?Sent:Friday, February 27, 2009 09:37
?To: postmodern-devel at common-lisp.net; 
?Subject:Re: [postmodern-devel] Get keys out of dao-class








Doesn't dao-keys work? There's no defun for it since it's a method.
 
Call it on a class to get the slot names, on an instance to get the
 
slot values.
 

 
Best,
 
Marijn
 

 
_______________________________________________
 
postmodern-devel mailing list
 
postmodern-devel at common-lisp.net
 
http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel







-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/postmodern-devel/attachments/20090227/70958976/attachment.html>

From zaries at global.co.za  Sat Feb 28 04:27:00 2009
From: zaries at global.co.za (Phil Marneweck)
Date: Sat, 28 Feb 2009 06:27:00 +0200
Subject: [postmodern-devel] Get keys out of dao-class
In-Reply-To: <MWS37dc8d1b3f9e314821abb5559209685f7a@mws37>
References: <MWS37dc8d1b3f9e314821abb5559209685f7a@mws37>
Message-ID: <1235795220.28093.5.camel@scatha>

Ok I figured it out, dao-keys "method" is a reader for effective-keys on
dao-class. I am still learning clos... *sigh*

On Fri, 2009-02-27 at 11:24 +0200, Phil Marneweck wrote:
> Thanx, I never thought about it being a method. I don't know how I
> missed it looking at the code. It works fine but I would like to
> understand how it works...
> 
> If I understand correctly there is two versions, the first returns a
> list of keys and the second returns a list of key values.
> 
> ;;first
> (defmethod dao-keys ((class-name symbol))
>   (dao-keys (find-class class-name)))
> 
> ;;second
> (defmethod dao-keys (dao)
>   (mapcar #'(lambda (slot)
>               (slot-value dao slot))
>           (dao-keys (class-of dao))))
> 
> Please explain to me how the first one works, to me it just looks like
> it calls itself?
> 
> Thanx
> 
> 
> 
>  ----- Original Message ------
>  From:Marijn Haverbeke
>  Sent:Friday, February 27, 2009 09:37
>  To: postmodern-devel at common-lisp.net; 
>  Subject:Re: [postmodern-devel] Get keys out of dao-class
> 
> 
> Doesn't dao-keys work? There's no defun for it since it's a method. 
> Call it on a class to get the slot names, on an instance to get the 
> slot values. 
> 
> Best, 
> Marijn 
> 
> _______________________________________________ 
> postmodern-devel mailing list 
> postmodern-devel at common-lisp.net 
> http://common-lisp.net/cgi-bin/mailman/listinfo/postmodern-devel
> 
> 
>