On Sun, Apr 14, 2013 at 7:03 PM, VernonCole <[email protected]> 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
