On Tue, Apr 30, 2013 at 9:45 PM, VernonCole <[email protected]> wrote:
> Dear knowledgeable persons: > > I have completed a beta-test version of a Linux remote access server for > adodbapi, and have started the process if integrating them into > django-mssql. (This is going to be an interesting experience for me -- I > have already identified two or three new features that adodbapi needs to > have.) I would like to get your collective wisdom about how to best > accomplish two things. > > 1) The transaction logic will change drastically for django 1.6. For the > supported backends it makes good sense to simply change that in the > repository. However, it is reasonable to expect significant code change > with the upgrade of this backend, and I think that we should maintain a > single code base for a while. I was thinking of behavior similar to what I > do inside of adodbapi: > > ...if sys.version_info >= (3,0): # note that the "if" is executed at > import time, not run time. > ......maxint = sys.maxsize > ...else: > ......maxint = sys.maxint > > Is there something more appropriate than django.VERSION to use for this, > or is it, perhaps, just a bad idea? > If the changes are relatively simple (or easily isolated), django.VERSION switching should work fine. As for whether this is a bad idea - It depends how hard it is to maintain the two side by side. If this will be constrained to a handful of branch points, in well isolated pieces of code, then it will be fairly easy to manage, and in the long term, deprecate the dead code branches. However, if the consequences of auto commit handling are spread throughout the codebase, and require lots of intricate changes, it may end up being a headache. The other approach would be to make versions hard matched -- i.e., django-mssql A.X works with Django 1.5, django-mssql A.Y works with Django 1.6. That way the code only ever has to support one Django version at a time, but the user will need to pay closer attention to which version of django-mssql they actually have deployed. If you want to be really friendly, you could make *this* a once off django.VERSION check. If you want to go all out, you could even mirror Django's versioning, so if you want to use Django 1.6, you need to use django-mssql 1.6 as well. However, that means your release schedule is tied to Django's, and could mean you're forced to make releases when you haven't actually made any significant changes to the codebase. Whether this matters is entirely up to you. > 2) In my unit test programs, I detect whether to use the proxy module or > the regular module depending on whether their is a certain key in the > connection arguments. > > .. import adodbapi > ...import adodbapi.remote > > ...if "proxy_host' in connection_keywords: > ......db = adodbapi.remote > ...else: > ......db = adodbapi > ...db_connection = db.connect(connection_keywords) > > Would there be any technical or political reasons NOT to do that in > sqlserver_ado/base.py ? > If proxy handling is that closely tied to the ADO interface, I'd say it makes sense to put it as close to the metal as possible. I can't think of any political reason not to; as for technical, it really only matters on how closely related proxy handling is to the core interface -- for example, would there be any use case for someone to want to define their own proxy interface. If there is, then you don't want them to be tightly bound; but if the proxy interface is really just another way to configure the connection, then you might as well embed it. 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.
