| 2011-06-17 20:26:54 |
Marc Tardif |
bug |
|
|
added bug |
| 2011-06-17 20:27:34 |
Marc Tardif |
description |
First, consider this SQL column definition:
date_created TIMESTAMP WITHOUT TIME ZONE
Second, consider this UTCDateTime property defined to set the timezone:
class UTCDateTimeVariable(DateTimeVariable):
def __init__(self, *args, **kwargs):
kwargs["tzinfo"] = pytz.timezone("UTC")
super(UTCDateTimeVariable, self).__init__(*args, **kwargs)
class UTCDateTime(DateTime):
variable_class = UTCDateTimeVariable
Third, consider this class definition referring to the above column definition and property:
class Foo:
date_created = UTCDateTime()
This works fine when getting an object directory from the store:
foo = store.get(Foo, 1)
print foo.date_created.tzinfo
<UTC>
However, this doesn't work when using an expression referring to the column:
foo = store.find((Foo, Max(Foo.date_created),)).get_one()
print foo.tzinfo
None
The problem seems to be that Expr statements like Max don't look into their expression arguments to determine how the object should be loaded. Instead, in the case of the postgres backend, they rely solely on the loading performed by psycopg2. Since most use cases for statements like Max pass properties as arguments, it would probably be desirable to check the arguments for the post appropriate way to load the objects. |
First, consider this SQL column definition:
date_created TIMESTAMP WITHOUT TIME ZONE
Second, consider this UTCDateTime property defined to set the timezone:
class UTCDateTimeVariable(DateTimeVariable):
def __init__(self, *args, **kwargs):
kwargs["tzinfo"] = pytz.timezone("UTC")
super(UTCDateTimeVariable, self).__init__(*args, **kwargs)
class UTCDateTime(DateTime):
variable_class = UTCDateTimeVariable
Third, consider this class definition referring to the above column definition and property:
class Foo:
date_created = UTCDateTime()
This works fine when getting an object directory from the store:
foo = store.get(Foo, 1)
print foo.date_created.tzinfo
<UTC>
However, this doesn't work when using an expression referring to the column:
(foo, max_date_created) = store.find((Foo, Max(Foo.date_created),)).get_one()
print max_date_created.tzinfo
None
The problem seems to be that Expr statements like Max don't look into their expression arguments to determine how the object should be loaded. Instead, in the case of the postgres backend, they rely solely on the loading performed by psycopg2. Since most use cases for statements like Max pass properties as arguments, it would probably be desirable to check the arguments for the post appropriate way to load the objects. |
|
| 2011-06-17 20:28:21 |
Marc Tardif |
description |
First, consider this SQL column definition:
date_created TIMESTAMP WITHOUT TIME ZONE
Second, consider this UTCDateTime property defined to set the timezone:
class UTCDateTimeVariable(DateTimeVariable):
def __init__(self, *args, **kwargs):
kwargs["tzinfo"] = pytz.timezone("UTC")
super(UTCDateTimeVariable, self).__init__(*args, **kwargs)
class UTCDateTime(DateTime):
variable_class = UTCDateTimeVariable
Third, consider this class definition referring to the above column definition and property:
class Foo:
date_created = UTCDateTime()
This works fine when getting an object directory from the store:
foo = store.get(Foo, 1)
print foo.date_created.tzinfo
<UTC>
However, this doesn't work when using an expression referring to the column:
(foo, max_date_created) = store.find((Foo, Max(Foo.date_created),)).get_one()
print max_date_created.tzinfo
None
The problem seems to be that Expr statements like Max don't look into their expression arguments to determine how the object should be loaded. Instead, in the case of the postgres backend, they rely solely on the loading performed by psycopg2. Since most use cases for statements like Max pass properties as arguments, it would probably be desirable to check the arguments for the post appropriate way to load the objects. |
First, consider this SQL column definition:
date_created TIMESTAMP WITHOUT TIME ZONE
Second, consider this UTCDateTime property defined to set the timezone:
class UTCDateTimeVariable(DateTimeVariable):
def __init__(self, *args, **kwargs):
kwargs["tzinfo"] = pytz.timezone("UTC")
super(UTCDateTimeVariable, self).__init__(*args, **kwargs)
class UTCDateTime(DateTime):
variable_class = UTCDateTimeVariable
Third, consider this class definition referring to the above column definition and property:
class Foo:
date_created = UTCDateTime()
This works fine when getting an object directory from the store:
foo = store.get(Foo, 1)
print foo.date_created.tzinfo
<UTC>
However, this doesn't work when using an expression referring to the column:
max_date_created = store.find(Max(Foo.date_created)).get_one()
print max_date_created.tzinfo
None
The problem seems to be that Expr statements like Max don't look into their expression arguments to determine how the object should be loaded. Instead, in the case of the postgres backend, they rely solely on the loading performed by psycopg2. Since most use cases for statements like Max pass properties as arguments, it would probably be desirable to check the arguments for the post appropriate way to load the objects. |
|
| 2011-06-18 17:34:17 |
Marc Tardif |
description |
First, consider this SQL column definition:
date_created TIMESTAMP WITHOUT TIME ZONE
Second, consider this UTCDateTime property defined to set the timezone:
class UTCDateTimeVariable(DateTimeVariable):
def __init__(self, *args, **kwargs):
kwargs["tzinfo"] = pytz.timezone("UTC")
super(UTCDateTimeVariable, self).__init__(*args, **kwargs)
class UTCDateTime(DateTime):
variable_class = UTCDateTimeVariable
Third, consider this class definition referring to the above column definition and property:
class Foo:
date_created = UTCDateTime()
This works fine when getting an object directory from the store:
foo = store.get(Foo, 1)
print foo.date_created.tzinfo
<UTC>
However, this doesn't work when using an expression referring to the column:
max_date_created = store.find(Max(Foo.date_created)).get_one()
print max_date_created.tzinfo
None
The problem seems to be that Expr statements like Max don't look into their expression arguments to determine how the object should be loaded. Instead, in the case of the postgres backend, they rely solely on the loading performed by psycopg2. Since most use cases for statements like Max pass properties as arguments, it would probably be desirable to check the arguments for the post appropriate way to load the objects. |
First, consider this SQL column definition:
date_created TIMESTAMP WITHOUT TIME ZONE
Second, consider this UTCDateTime property defined to set the timezone:
class UTCDateTimeVariable(DateTimeVariable):
def __init__(self, *args, **kwargs):
kwargs["tzinfo"] = pytz.timezone("UTC")
super(UTCDateTimeVariable, self).__init__(*args, **kwargs)
class UTCDateTime(DateTime):
variable_class = UTCDateTimeVariable
Third, consider this class definition referring to the above column definition and property:
class Foo:
date_created = UTCDateTime()
This works fine when getting an object directly from the store:
foo = store.get(Foo, 1)
print foo.date_created.tzinfo
<UTC>
However, this doesn't work when using an expression referring to the column:
max_date_created = store.find(Max(Foo.date_created)).get_one()
print max_date_created.tzinfo
None
The problem seems to be that Expr statements like Max don't look into their expression arguments to determine how the object should be loaded. Instead, in the case of the postgres backend, they rely solely on the loading performed by psycopg2. Since most use cases for statements like Max pass properties as arguments, it would probably be desirable to check the arguments for the post appropriate way to load the objects. |
|
| 2011-06-18 17:35:03 |
Marc Tardif |
description |
First, consider this SQL column definition:
date_created TIMESTAMP WITHOUT TIME ZONE
Second, consider this UTCDateTime property defined to set the timezone:
class UTCDateTimeVariable(DateTimeVariable):
def __init__(self, *args, **kwargs):
kwargs["tzinfo"] = pytz.timezone("UTC")
super(UTCDateTimeVariable, self).__init__(*args, **kwargs)
class UTCDateTime(DateTime):
variable_class = UTCDateTimeVariable
Third, consider this class definition referring to the above column definition and property:
class Foo:
date_created = UTCDateTime()
This works fine when getting an object directly from the store:
foo = store.get(Foo, 1)
print foo.date_created.tzinfo
<UTC>
However, this doesn't work when using an expression referring to the column:
max_date_created = store.find(Max(Foo.date_created)).get_one()
print max_date_created.tzinfo
None
The problem seems to be that Expr statements like Max don't look into their expression arguments to determine how the object should be loaded. Instead, in the case of the postgres backend, they rely solely on the loading performed by psycopg2. Since most use cases for statements like Max pass properties as arguments, it would probably be desirable to check the arguments for the post appropriate way to load the objects. |
First, consider this SQL column definition:
date_created TIMESTAMP WITHOUT TIME ZONE
Second, consider this UTCDateTime property defined to set the timezone:
class UTCDateTimeVariable(DateTimeVariable):
def __init__(self, *args, **kwargs):
kwargs["tzinfo"] = pytz.timezone("UTC")
super(UTCDateTimeVariable, self).__init__(*args, **kwargs)
class UTCDateTime(DateTime):
variable_class = UTCDateTimeVariable
Third, consider this class definition referring to the above column definition and property:
class Foo:
date_created = UTCDateTime()
This works fine when getting an object directly from the store:
foo = store.get(Foo, 1)
print foo.date_created.tzinfo
<UTC>
However, this doesn't work when using an expression referring to the column:
max_date_created = store.find(Max(Foo.date_created)).get_one()
print max_date_created.tzinfo
None
The problem seems to be that Expr statements like Max don't look into their expression arguments to determine how the object should be loaded. Instead, in the case of the postgres backend, they rely solely on the loading performed by psycopg2. Since most use cases for statements like Max pass properties as arguments, it would probably be desirable to check the arguments for the most appropriate way to load the objects. |
|
