headers
Jeremy Fitzhardinge | 3 Aug 2004 02:58
Gravatar

A couple of patches: SELECT DISTINCT and index creation

Here's a couple of patches I've been using locally with some success.

The first implements DISTINCT.  It behaves a lot like reverse(): you can
either say:
	Foo.select(..., distinct=True)
or
	res = Foo.select(...)
	res.distinct()

	# use res...

This only applies to explicit select() calls.  It doesn't really combine
properly with count(*) either; it seems the correct way to do that is
count(distinct *), but sqlite (my testing DB) doesn't implement that,
and needs a much more complex variant using DISTINCT sub-selects.  So
I've ignored that for now.

The second is an updated version of the patch I posted the other day.
It allows you to specify indexes when defining a table class.  There's
an example at the top of the patch.

Both patches are against the current SVN head.

I'd be interested to know if anyone finds these useful, or if I'm just
barking up the wrong tree.

Thanks,
	J
Attachment (distinct-select.patch): text/x-patch, 3366 bytes
(Continue reading)

Permalink | Reply | 0 comments |
headers
l.m.orchard | 11 Aug 2004 16:42

datetime vs mx.DateTime

Heya - I'm wondering if there's a way that I can force SQLObject to use 
datetime from the Python standard modules, as opposed to mx.DateTime?

I have an app that was written expecting the datetime interface 
everywhere, and then mx.DateTime was installed.  Now things are 
breaking because the expected datetime objects are returned as 
mx.DateTime, which has a totally different set of methods and 
properties.

Any advice?  (And uninstalling mx.DateTime is not one of my options.  
Also, rewriting the app to use mx.DateTime is the least favorable 
outcome.)

Thanks!

--
l.m.orchard <deus_x <at> pobox.com> http://www.decafbad.com/
...see you space cowboy.

-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
Permalink | Reply | 1 comment |
headers
Mike Watkins | 11 Aug 2004 17:16

Re: datetime vs mx.DateTime

On Wed, 2004-08-11 at 07:42, l.m.orchard wrote:
> Heya - I'm wondering if there's a way that I can force SQLObject to use 
> datetime from the Python standard modules, as opposed to mx.DateTime?

Probably. Depends.

"Depends", as some DBAPI modules require mx.DateTime - psycopg, for
example. If you are using a DBAPI module that can utilize the Python
datetime module, you could have your own conversion override the default
date/time conversion in SQLObject.

To do this, create your own load point for SQLObject rather than
importing everything from the module itself.

i.e.

mysqlobject.py:

# a convenient load point for our custom hacked SQLObject
from sqlobject import *
from sqlobject.col import *
from sqlobject.col import SOCol
from sqlobject import constraints

# and hack/define your own Date col type, converters.
... for you to do.. ;-)

-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
(Continue reading)

Permalink | Reply | 0 comments |
headers
CLIFFORD ILKAY | 13 Aug 2004 03:11

GROUP BY Clause - Looking for Workaround

Hi,

I understand SQLObject does not support GROUP BY but is there a way to pass 
it through to the back end anyway? I am trying to the do equivalent of:

select group_id, count(*) from person where (expiry = '12/31/2003' or 
expiry = '12/31/2004') and active = 'YES';

Regards,

Clifford Ilkay
Dinamis Corporation
3266 Yonge Street, Suite 1419
Toronto, Ontario
Canada M4N 3P6

Tel: 416-410-3326  

-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
Permalink | Reply | 0 comments |
headers
Dennis Heuer | 13 Aug 2004 21:44

support for gadfly

http://gadfly.sourceforge.net/

Hello,

I wanted to mention the RDBMS Gadfly because it is written completely in python, transaction safe and comes
with a server. It is very useful for e.g. desktop installations or live-cd's (installation support,
demonstration, etc.). It just works without the need for pre-installation like SQLite. By the way, it
marshals objects. There's no need for type conversions. This may help supporting it.

Regards,
Dennis

-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
Permalink | Reply | 0 comments |
headers
Chris Gahan | 14 Aug 2004 20:16
Gravatar

Re: Adding DB auto-timestamping to DateTimeCol

On 30 Jul 2004, Mike Watkins said:

> class Test(SQLObject):
>   foo=StrCol(length=20, default=None)
>   creation_date=DateTimeCol(default=None)
> 
> When creating new Test objects, I do not want creation_date to be set
> to null; I want the database to look after setting defaults. For the
> time being I am passing a function
> 
>   creation_date=DateTimeCol(default=date.now)
> 
> but that doesn't truly resolve the issue for me as I'd prefer to have
> the database (postgres) deal with the time stamps. This makes it
> easier to coexist with other apps or sql scripts directly manipulating
> the DB. 

That's a good point. With a cluster of machines making calls to one
central database, the date.now() could return a different time depending
on which machine the code was being run on. And, as you said, it's
better to let the DB do the timestamping when you're mixing SQLObject
with other non-SQLObject apps that also use the DB. 

I think we should fix this. How about adding a boolean to the
DateTimeCol class' constructor, like this: 

    timestamp = DateTimeCol(autoTimestamp=True)

That could work. Is "autoTimestamp" a keyword people are familiar with?
:)
(Continue reading)

Permalink | Reply | 4 comments |
headers
Luke Opperman | 14 Aug 2004 21:51

Re: Re: Adding DB auto-timestamping to DateTimeCol

> I think we should fix this. How about adding a boolean to the
> DateTimeCol class' constructor, like this:
>
>    timestamp = DateTimeCol(autoTimestamp=True)
>
> That could work. Is "autoTimestamp" a keyword people are familiar with?
> :)

Isn't this a more generic idea, saying "not a required field, and don't include
when creating"? Ie, a flag that could apply to any Col type, not just
DateTimeCol? Right now, my understanding is that we can have fields that
aren't required for creating SO objects, but SO requires a default
value/function to use in that case and includes it in the INSERT statement.
Not sure what word to use for the flag, "auto" by itself is the right concept
but pretty generic. "autoInsert"? "databaseDefault"? "defaultFromDatabase"?

- Luke

-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
Permalink | Reply | 3 comments |
headers
Andrew Bennetts | 15 Aug 2004 02:10
Favicon

Re: Re: Adding DB auto-timestamping to DateTimeCol

On Sat, Aug 14, 2004 at 02:51:28PM -0500, Luke Opperman wrote:
[...]
> 
> Isn't this a more generic idea, saying "not a required field, and don't 
> include
> when creating"? Ie, a flag that could apply to any Col type, not just
> DateTimeCol? Right now, my understanding is that we can have fields that
> aren't required for creating SO objects, but SO requires a default
> value/function to use in that case and includes it in the INSERT statement.
> Not sure what word to use for the flag, "auto" by itself is the right 
> concept
> but pretty generic. "autoInsert"? "databaseDefault"? "defaultFromDatabase"?

There's already a "default" flag.  When left with its default value
(NoDefault), probably SQLObject should just omit it from the INSERT
statement, rather than refuse to even try (or perhaps there should be a
default=OmitOk or something).  Currently, there's no way to make use of a
"DEFAULT ..." declaration in a table definition.

-Andrew.

-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
Permalink | Reply | 2 comments |
headers
Dennis Heuer | 15 Aug 2004 14:12

transactions

Hello,

your documentation is quite unclear about transactions. It says that SQLite and MySQL don't support
transactions. However, both SQLite and MySQL *support* transactions, and the python modules do as well.
In the case of MySQL support depends on the table type. MySQLdb checks for that and always succeeds
gracefully. However, I don't know if SQLObject supports setting the table type when creating a table. 

The documentation does not say if SQLObject at least tries to start a transaction and catches the
exception. What is actually happening when I'm using the trans object with SQLite or MySQL? 

Please, forSQLObject 0.6, at least try to start the transaction (best based on the supported modules) and
provide a way to select the table type for MySQL.

When do you expect the next release of SQLObject?

Thanks,
Dennis

-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
Permalink | Reply | 0 comments |
headers
Dennis Heuer | 15 Aug 2004 15:49

column types

Hello again,

your column types are somewhat unclean. For example, why you use INT for a boolean value. The most close type
would be TINYINT (SMALLINT where TINYINT isn't supported). Using a CHAR(1) and character-set safe binar
values like \x60 and \x61 is another alternative.

Your StringCol(length) seems to be byte-oriented. It would be nice if there was a character-based length attribute.

Regards,
Dennis

-------------------------------------------------------
SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
Permalink | Reply | 1 comment |

Gmane