Re: survey question: should UUID database fields be returned as instances of class "uuid"? (re: ticket 19463)

[Michael Manfre]

On Mon, Apr 15, 2013 at 1:51 AM, VernonCole  wrote:

> So -- is it worth my time to muck with direct database api support of uuid
> fields?
>

Add the support. Each database backend defines the mapping for the core
model field types (see DatabaseCreation.data_types) and any non-standard
model fields can define their own mapping by overriding Field.db_type().
The app django-uuidfield [1] allows postgres to store UUIDs as it's uuid
type and translates it to a hex string for the Django side of things. You
could easily mimic the behavior or keep it as a UUID from end-to-end.

If/when Django adds UUIDField to the core field types, each backend can
define the appropriate column type (BINARY(16), CHAR(32), uuid,
UNIQUEIDENTIFIER, etc).

[1]
https://github.com/dcramer/django-uuidfield/blob/master/uuidfield/fields.py

Regards,
Michael Manfre

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: survey question: should UUID database fields be returned as instances of class "uuid"? (re: ticket 19463)

[VernonCole]

Russ:

 I am not entirely sure what I am asking, either, but your answer has 
already helped.  Indeed, PEP 249 is silent about support of UUID feilds, 
because it was written too long ago.  It is also silent about support of 
decimal and datetime fields for the same reason.  You have just taught me 
why we (meaning myself and other db-api authors) need a new, updated PEP.

As for "whoever is responsible" -- that's me!  I am the guy who maintains 
the Python ADO module.  I am in the middle of an effort to upgrade that 
module specifically for django's benefit. My problem is that I have so 
little experience as a _user_ of django that I'm not a good judge of what 
we (meaning other django users) really need. I feel like a guy who doesn't 
know how to drive designing a new car.  That's why I am asking so many 
off-the-wall questions to this group.  I need someone to say: "No, we 
really need the steering wheel to stay where it is... Now if you can do 
something about needing one foot for the gas, and one foot for the brake, 
and one foot for the clutch in order to start on a hill -- we could really 
use THAT,"

So, if I were to add direct UUID support to adodbapi, it might eventually 
get included in a new PEP, and eventually picked up by the likes of 
psycopg.  No guarantees, but it would be a start.  

My present project is to make a way for Linux users to have a door into 
ADO. That ought to help to gain some traction for django-mssql, which is 
why I am here.  I have been seeing a use for this for ages -- but am now 
working for a company who needs to have the feature working -- about three 
weeks ago. If I mention that the UUID field I am working with happens to be 
in a record of collected data points which I also need to put on a map in 
geo-django, which does not work with django-mssql (yet, and I am still 
learning geo-django) you have an idea why I need wise advice whenever I can 
get it.  Thank you. You are helping eHealth Africa to put an end to polio.

So -- is it worth my time to muck with direct database api support of uuid 
fields?  

Where am I in relation to: "Now is better than never.
Although never is often better than *right* now."?
--
Vernon

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: survey question: should UUID database fields be returned as instances of class "uuid"? (re: ticket 19463)

[Russell Keith-Magee]

On Sun, Apr 14, 2013 at 7:03 PM, VernonCole  wrote:

> While mucking with the refactoring of adodbapi, I included a patch fixing
> a bug when storing data into columns of type "adGUID".  I had not been
> really aware that SQL Server has a dedicated data type for UUID until that
> ticket surfaced.  Then I started thinking about the column in one of my CDC
> data tables which contains text which always contains "uuid:" followed by a
> long hexadecimal looking string. I am pretty sure it was once a primary
> key, but pending something like ticket 19463 I don't use it as such.
> Nevertheless, it started me thinking...
>
> When I read data columns written in native decimal or date-time formats, I
> make the db-api module emit good, proper Python decimal.decimal and
> datetime.datetime objects. It would not take much effort to perform a
> similar action when I see that the incoming column is of the Windows type
> "adUUID" -- I could emit an instance of the "uuid" class.
>
> Is that a good idea, or a bad idea?
>

I'm not entirely sure what you're asking here.

Jacob has already given the green light to a UUID field. We're just waiting
for an appropriate patch. So if you want to support UUID types, that's the
first step -- but it's unrelated to the development of an Django ADO
database backend.

The decision to emit an instance of a UUID class is a function of the
pyDB-API layer, so that's something to take up with whoever is responsible
with the Python ADO bindings. Again, it's not a Django DB backend question.
PEP249 doesn't mention UUID types, however, so I'm not sure what the
appropriate behaviour would be.

Have I missed the point of what you're asking?

Yours
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

survey question: should UUID database fields be returned as instances of class "uuid"? (re: ticket 19463)

[VernonCole]

While mucking with the refactoring of adodbapi, I included a patch fixing a 
bug when storing data into columns of type "adGUID".  I had not been really 
aware that SQL Server has a dedicated data type for UUID until that ticket 
surfaced.  Then I started thinking about the column in one of my CDC data 
tables which contains text which always contains "uuid:" followed by a long 
hexadecimal looking string. I am pretty sure it was once a primary key, but 
pending something like ticket 19463 I don't use it as such.  Nevertheless, 
it started me thinking...

When I read data columns written in native decimal or date-time formats, I 
make the db-api module emit good, proper Python decimal.decimal and 
datetime.datetime objects. It would not take much effort to perform a 
similar action when I see that the incoming column is of the Windows type 
"adUUID" -- I could emit an instance of the "uuid" class.

Is that a good idea, or a bad idea?
--
Vernon Cole
 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.