Re: How to deal with backend-specific parameter types? [Was: django on jython (new version)?]

2007-09-09 Thread Leo Soto M.

On 9/6/07, David Elias <[EMAIL PROTECTED]> wrote:

> Some backends provide some type_cast functions that you can attach to
> some data types, on a quick search for zxJDBC I found in the home page
> "Datatype mapping callbacks through DataHandler", don't know if this
> has the same functionality just had a quick look.

Thanks, it looks possible to solve this problem with a custom DataHandler.

Although it's not a direct conversion path (datetime -> string ->
java.sql.TimeStamp), it has the benefit that doesn't mess with Django
internals.

-- 
Leo Soto M.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---



How to deal with backend-specific parameter types? [Was: django on jython (new version)?]

2007-09-06 Thread Leo Soto M.

On 9/5/07, Marty Alchin <[EMAIL PROTECTED]> wrote:
>
> That is excellent news! I'm especially excited to hear about the
> inclusion of pop() on PyStringMap, since that would indeed solve a few
> metaclass issues with Django (and perhaps others). It's starting to
> sound like with a decent recent Jython SVN, we might be able to have
> Django working soon with just a proper set of JDBC drivers.

Yeah. But I'm somewhat stuck with the db backend plumbing, mainly
because zxJDBC has some different expectations about the type of
execute() parameters.

One case is about dates, times and datetimes. This is a interesting
part on DateTimeField: the get_db_prep_save() method:

def get_db_prep_save(self, value):
# Casts dates into string format for entry into database.
if value is not None:
if settings.DATABASE_ENGINE == 'mysql' and hasattr(value,
'microsecond'):
value = value.replace(microsecond=0)
value = smart_unicode(value)
return Field.get_db_prep_save(self, value)

The problem is that, at least the postgresql driver wants a
java.sql.Timestamp parameter, not a string one. AFAIK, the same
happens with other JDBC drivers.

As I see that at least one special case is handled inside this method,
I could write another one for JDBC drivers:

if 'zxjdbc' in settings.DATABASE_ENGINE:
from com.ziclix.python.sql import zxJDBC
value =  zxJDBC.Timestamp(value.year, value.month, value.day,
  value.hour, value.minute, value.second)

But that smells bad.

Using an adaptation protocol seems like a good option to me. For
example, on Field.save() instead of doing:

db_values = [f.get_db_prep_save(raw and getattr(self, f.attname)
or f.pre_save(self, False)) for f in non_pks]

One could write something like:

db_values = [connection.adapt_field_value(f, self) for f in non_pks]

Am I on the right track? Do you people have other ideas?

-- 
Leo Soto M.

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---