RELEASE: psycopg 1.0.14pre1

hi *,

here is a pre-release of psycopg 1.0.14:

  http://initd.org/pub/software/psycopg/psycopg-1.0.14pre1.tar.gz

that fixed almost all of the bugs reported in the last 2 months. it
should even work with zope 2.6 from cvs (sortKey() problem). here is the
NEWS entry:

psycopg news for 1.0.14
-----------------------

* Fixed some memory leaks and segfaults:
  - memleak reported by John Goerzen
  - segfault reported by Marius Gedminas on Debian BTS

* psycopg now _probably_ works with Zope 2.6 from CVS.

-----------------------

if you have SSL-related problems (like an ssl-enable postgresql on new
unstable debians), configure as follows:

  LIBS=-lssl ./configure blah blah ...

please report any bugs before I release 1.0.14 final during next
weekend.

--

-- 

RELASE: psycopg 1.0.14pre2

psycopg 1.0.14pre1 was unbuilable on python < 2.2. pre2 solves the
problem. download from:

  http://initd.org/pub/software/psycopg/psycopg-1.0.14pre2.tar.gz

people grabbing it from cvs, remember to use the PSYCOPG-1-0 branch.

have fun,
federico

--

-- 
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact        fog@...
INIT.D Developer                                           fog@...
             A short story: I want you. I love you. I'll miss you. -- Me

problems installing on Zope-2.6

Hello,
I've been using Zope 2.4 and PSycopgDA with no problems,
including a recent reinstall without a hitch. But I'm trying
to update to Zope-2.6 and am not having success with the
PSycopg part. It keeps complaining that
    "Zope cannot import Products.PSycopgDA"

One difference between the new and older zope versions
is that under $ZOPE/lib there are now 2 python dirs,
"python" and "python2.1". Only the python dir has the'
Products/PSycopgDA directories. But zope seems to want
both python dirs to run.

I've also tried copying the Product/PSycopgDA directory
from python->python2.1 dirictory, but nothing seems to
make zope able to import successfully. Thanks for any
help or advice you can offer,
Sincerely
Charles Cosse
ccosse at psl.nmsu.edu

Re: problems installing on Zope-2.6

Scavenging the mail folder uncovered ccosse's letter:
> Hello,
> I've been using Zope 2.4 and PSycopgDA with no problems,
> including a recent reinstall without a hitch. But I'm trying
> to update to Zope-2.6 and am not having success with the
> PSycopg part. It keeps complaining that
>    "Zope cannot import Products.PSycopgDA"

use psycopg 1.0.14pre2 released 2 days ago.

> One difference between the new and older zope versions
> is that under $ZOPE/lib there are now 2 python dirs,
> "python" and "python2.1". Only the python dir has the'
> Products/PSycopgDA directories. But zope seems to want
> both python dirs to run.
> 
> I've also tried copying the Product/PSycopgDA directory
> from python->python2.1 dirictory, but nothing seems to
> make zope able to import successfully. Thanks for any
> help or advice you can offer,

i don't know how this works. it seems usual precompiled 
zope crappines at work <g>. i'll start testing on zope 2.6
next week..

--

-- 
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact        fog@...
  Those who do not study Lisp are doomed to reimplement it. Poorly.
                                     -- from Karl M. Hegbloom .signature

Re: problems installing on Zope-2.6

Hello ccosse,

Wednesday, December 4, 2002, 10:25:05 PM, you wrote:

c> Hello,
c> I've been using Zope 2.4 and PSycopgDA with no problems,
c> including a recent reinstall without a hitch. But I'm trying
c> to update to Zope-2.6 and am not having success with the
c> PSycopg part. It keeps complaining that
c>     "Zope cannot import Products.PSycopgDA"

c> One difference between the new and older zope versions
c> is that under $ZOPE/lib there are now 2 python dirs,
c> "python" and "python2.1". Only the python dir has the'
c> Products/PSycopgDA directories. But zope seems to want
c> both python dirs to run.

c> I've also tried copying the Product/PSycopgDA directory
from python->>python2.1 dirictory, but nothing seems to
c> make zope able to import successfully. Thanks for any
c> help or advice you can offer,
c> Sincerely
c> Charles Cosse
c> ccosse at psl.nmsu.edu

We have installed zope 2.6 from package (debian), psycopg 1.1 and
ZPSycopgDA from source and everything works. In our $ZOPE/lib
there are only 1 directory python. You wrote "Products/PSycopgDA"
not "Products/ZPSycopgDA", is it mistake or folder name really
"PSycopgDA"? Maybe it's the cause?

Re: problems installing on Zope-2.6

Why does TimestampFromMx chop off the milliseconds?

Why, oh why, do the various Time* functions in psycopg ignore 
fractional seconds?

I really need to preserve fractional seconds.  I just noticed that all 
of my timestamps were truncated by psycopg.  I can see two potential 
workarounds, use the str() function on my mx.DateTime object and insert 
the string.  The other option is to fix the source to psycopg so that 
these functions don't truncate my timestamps.  I guess that's not 
really a workaround, that open source. 

What really has me perplexed is that psycopg properly retains the 
fractional seconds when converting
a database timestamp field into a mx.DateTime object.  WTF?

Thanks a lot,
	Chris

--

-- 
Christopher Douty <Chris_Douty@...> +1-650-367-3129
Senior Engineer, Software & Systems  - AMPEX Data Systems Corp.

Re: Why does TimestampFromMx chop off the milliseconds?

Hi all,

I know it's bad form to respond to yourself, but I figured out why 
psycopg.TimestampFromMX() chops off the fractional seconds.  Internally 
the strftime method of mx.DateTime objects is used, and the strftime 
function has no way to specify fractional seconds in the output.  
Additionally, the struct tm data type only uses an integer number of 
seconds.

I was able to successfully use str() on my DateTime objects to get a 
full timestamp like I wanted.

Now I am fighting a different battle.  Sometimes the original 
mx.DateTime object I inserted and the one retrieved from the database 
do not match.  I think that it probably has something to do with 
floating point rounding errors.

For example.

 >>> t1 = DateTime(2002,12,4,14,27,2.170)
 >>> str(t1)
'2002-12-02 16:27:02.16'
 >>> t1.absvalues()
(731186, 59222.169999999998)
 >>> 2+170/1000.0     # Which is how I calculate seconds for the 
DateTime constructor
2.1699999999999999

I think that the problem is that str() on a DateTime object truncates 
the seconds value at 2 digits, and there's no way I've fond to get it 
to give more precision or round correctly.  O suppose that I could make 
my own version of strftime that does what I want in python.  Gah.

Cheers,
	Chris

On Wednesday, December 4, 2002, at 01:38 PM, Chris Douty wrote:

> Why, oh why, do the various Time* functions in psycopg ignore 
> fractional seconds?
>
> I really need to preserve fractional seconds.  I just noticed that all 
> of my timestamps were truncated by psycopg.  I can see two potential 
> workarounds, use the str() function on my mx.DateTime object and 
> insert the string.  The other option is to fix the source to psycopg 
> so that these functions don't truncate my timestamps.  I guess that's 
> not really a workaround, that open source. 
>
> What really has me perplexed is that psycopg properly retains the 
> fractional seconds when converting
> a database timestamp field into a mx.DateTime object.  WTF?

--

-- 
Christopher Douty <Chris_Douty@...> +1-650-367-3129
Senior Engineer, Software & Systems  - AMPEX Data Systems Corp.

Exception handling with ZPsycopgDA

Howdy,

I'm using Zope 2.5.0 and ZPsycopgDA. I am having trouble handling execptions.
Zope hangs when I try. Here is the Python Script (not external) I use in
Zope:

    # spend_time(proj_id, start_date, end_date, proj_plan)
    #
    # put time into database for weeks from start_date to end_date (inclusive)
    #
    # start_date and end_date are date strings that PostgreSQL understands
    #
    # proj_plan is a dictionary where the keys are category ids and the
    # values are days spent over the time period.
    #

    import re

    n_weeks = context.delta_weeks_from_dates(
                start_date=start_date, end_date=end_date)[0].weeks

    start_day = container.monday_from_date(date=start_date)[0].monday
    end_day = container.monday_from_date(date=end_date)[0].monday

    proj_name = context.projname_by_id(proj_id=proj_id)

    bl_result = ""
    bl_error = ""
    for i in range(n_weeks):
        # insert info for 'week'
        for cat_id in proj_plan.keys():
            try:
                if float(proj_plan[cat_id]) >= 0.001:
                    q = """insert into spent_time (project,
                                           category,
                                           time,
                                           username,
                                           cal_week,
                                           date_added)
                                   values (%s,
                                           %s,
                                           '%s Days',
                                           '%s',
                                           '%s'::date + %d,
                                           'now')""" % \
                                          (proj_id, \
                                           cat_id, \
                                           float(proj_plan[cat_id]) / n_weeks, \
                                           request.AUTHENTICATED_USER, \
                                           start_day, i * 7)

                    # bl_result = bl_result + "%s<br>\n" % q
                    try:
                        context.genericQuery(query=q)
                    except StandardError, e:
                        bl_result = bl_result + "An error occured: " +str(e)
            except:
                pass

    
    bl_result = bl_result +  "%s: %s" % (proj_name, bl_error)

    return bl_result

genericQuery is a ZSql method that takes on argument, a query string, and
executes it. It's contents are:

    <dtml-var query>

When I call the python script and ZPsycopgDA raises an exception, Zope
hangs. Currently, the exception I am interested in handling is an
IntegrityError when a duplicate item is inserted.

Any help/guidance will be greatly appreciated.

Jeff.
--

-- 
Jeff Putsch                       Email: putsch@...
Maxim Integrated Products        Office: (503)547-2037
High Frequency CAD Engineering

Re: Why does TimestampFromMx chop off the milliseconds?

Il gio, 2002-12-05 alle 02:21, Chris Douty ha scritto:
> Hi all,
> 
> I know it's bad form to respond to yourself, but I figured out why 
> psycopg.TimestampFromMX() chops off the fractional seconds.  Internally 
> the strftime method of mx.DateTime objects is used, and the strftime 
> function has no way to specify fractional seconds in the output.  
> Additionally, the struct tm data type only uses an integer number of 
> seconds.

you're right.

> I was able to successfully use str() on my DateTime objects to get a 
> full timestamp like I wanted.
> 
> Now I am fighting a different battle.  Sometimes the original 
> mx.DateTime object I inserted and the one retrieved from the database 
> do not match.  I think that it probably has something to do with 
> floating point rounding errors.
> 
> For example.
> 
>  >>> t1 = DateTime(2002,12,4,14,27,2.170)
>  >>> str(t1)
> '2002-12-02 16:27:02.16'
>  >>> t1.absvalues()
> (731186, 59222.169999999998)
>  >>> 2+170/1000.0     # Which is how I calculate seconds for the 
> DateTime constructor
> 2.1699999999999999

this is a generic problem of the floating point format. note that even C
or any other programming language using floating point values has this
problem.

> I think that the problem is that str() on a DateTime object truncates 
> the seconds value at 2 digits, and there's no way I've fond to get it 
> to give more precision or round correctly.  O suppose that I could make 
> my own version of strftime that does what I want in python.  Gah.

if you do, please post it to the ML, to be included in future psycopg
releases. a better way would be to patch mx.DateTime and/or strftime..

--

-- 
Federico Di Gregorio
Debian GNU/Linux Developer & Italian Press Contact        fog@...
INIT.D Developer                                           fog@...
                             Best friends are often failed lovers. -- Me