Re: Proposal for prepared statements API

There was a recent query about prepared statements on the db-sig mailing list, too. Apparently thought is being given to adding such functionality to Psycopg. If such functionality is added, it could be useful to support, I suppose. Some SQL engines apparently benefit from the techinque. MS SQL

Re: An improved settings.py configuration (revisited)

14 at 3:14 AM, Carl Meyer <ca...@oddbird.net > > wrote: > >> Hi Vernon, >> >> On 03/07/2014 07:44 PM, VernonCole wrote: >> > Several months ago, I floated an idea on this forum for re-structuring >> > the settings.py environment. >> > >>

An improved settings.py configuration (revisited)

Several months ago, I floated an idea on this forum for re-structuring the settings.py environment. It generated a fair amount of discussion. The consensus was that something really ought to be done, but no one was sure just what. One strong opinion was that any new changes must involve a

Re: Using setuptools to make django-admin.py runnable on Windows (#21340)

Waylan is correct, but does not go far enough. When one installs Python 3.3, the Python Launcher for Windows is also installed. I install Python 3 even on systems where I do not (at present) plan to use it, just to get the launcher. The launcher is the program which should be associated with

Re: Add strutctured settings module to django 1.7?

Not off topic at all, Carl, this back-and-forth is helping me, at least, consider some new things. Here's what I have learned from this discussion so far: 1. Clearly, any change needs to avoid use of the word "structured", since that is now yesterday-ish. 2. Any change needs to lead toward

Re: Add strutctured settings module to django 1.7?

> encouraging any particular path at present. There isn't a clear consensus > as to the best way forwards. > > > On 26 September 2013 11:11, VernonCole <verno...@gmail.com > >wrote: > >> >> Okay, I read it. I think that it argues for structured settings, not

Re: Add strutctured settings module to django 1.7?

n Thursday, September 26, 2013 12:45:20 AM UTC+1, Russell Keith-Magee wrote: > > > On Thu, Sep 26, 2013 at 4:21 AM, VernonCole <verno...@gmail.com > > wrote: > >> I find myself using up lots of time and keystrokes explaining about the >> benefits and methods

Add strutctured settings module to django 1.7?

I find myself using up lots of time and keystrokes explaining about the benefits and methods of a structured settings module in django. For example: Using-a-Structured-Settings-environment It occurs to me that

Re: Order of INSTALLED_APPS

It also affects _how_ South works, not just _whether_ it works. Only this week I had to install a patch for the formhub package which consisted of re-ordering INSTALLED_APPS so that tables were built in the correct order on PostgreSQL installations. On Sunday, September 1, 2013 11:04:03 PM

Re: tests failing/throwing errors - not sure where to start

Kris: 9 failures and 17 errors are not an unusual number (out of 556 tests) given the complexity of django and the number of platforms it works on. The number and selection of failed tests will vary depending on the exact implementation you are running. However, I notice that _none_ of the

Re: Deprecate FCGI support in Django 1.7

Let me second the need for a good "How To" document on deployment. As a neophyte django user I suddenly felt very lost last week. After several months of development, the ADO interface to the Microsoft SQL server from Linux is working (it still needs some tuning, but the data does go in and

Re: Supported Python versions for Django 1.7

Dropping support of 3.2 would potentially aid projects which have not yet converted to Python 3, since Python 3.3 supports u"Unicode Literals" but 3.2 does not. Skipping over the early 3.x versions vastly eases transition from 2.6 to 3.3. Besides, what are the chances that someone running

Re: Testing generated SQL under different backends

I have just run afoul of one of those "features that make no sense except when combined with the test suite."In BaseDatabaseFeatures it looks like this: # Does the backend allow very long model names without error? supports_long_model_names = True What this flag actually does is

Re: Passing parameters to raw()

Understand that this will not affect django for the next several releases. Probably django 2.0. The transition from db-api 2 to db-api 3 will be a lot like the transition from Python 2 to Python 3. You will have to import a different module to get the different behavior, and today's api-2

Re: Passing parameters to raw()

Officially (according to PEP-249) you are not supposed to be able to do that (pass a dictionary of parameters), but PostgreSQL does it as an extension to the spec. SQLite and ms-sql (both of which use format converters to send your queries out with '?' where you put the '%s') do NOT support

Re: django and paramstyle: what's the actual story?

inners in the parmstyle competition ('named', 'qmark')? -- Vernon Cole On Thursday, May 16, 2013 7:49:47 PM UTC+1, Shai Berger wrote: > > On Thursday 16 May 2013, VernonCole wrote: > > I noticed in a recent post that there is an outstanding patch for Oracle > > for support

Cursor closing or reuse: am I missing something?

My testing of remote mssql is proceeding nicely, or was until a few days ago. After much debugging it looks like my database proxy server may be running out of worker threads: it uses one for each cursor. My traces show that, when running the test suite in django-mssql (using ./manage.py

Progress report: django-mssql for Linux

Hello all: I just want to let everyone know what has happened on this proposal in the last little while. 1) The combination of a Linux (or Windows) database client with a Windows proxy database server is up and running. The remote supports all of the features of adodbapi (when run locally)

Re: Test failures under Oracle

How about creating django.contrib.db.backends for databases with a small maintainer "bus size" number? Oracle and django-mssql could live there. They would have less than full support, but still some level of official recognition? -- Vernon Cole On Wednesday, May 1, 2013 4:31:58 AM UTC-6,

design decisions for django-mssql: (switching on autocommit and remote proxy) advice wanted.

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

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

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

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

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

Re: Extending the DATABASES = {'xx': {'NAME': construct to carry additional information and / or virtual names

On Monday, April 8, 2013 3:31:48 AM UTC-6, Aymeric Augustin wrote: > > On 8 avr. 2013, at 10:21, VernonCole <verno...@gmail.com > > wrote: > > > 1) re-implement the argument signature of adodbapi so that it agrees > with the recommendation for positional and k

Re: currency of DATABASES = {'xx' : {'OPTIONS' = {'AUTOCOMMIT' ... flag.

On Monday, April 8, 2013 3:17:52 AM UTC-6, Aymeric Augustin wrote: > > On 8 avr. 2013, at 10:33, VernonCole <verno...@gmail.com > > wrote: > > > I am confused by the documentation. I cannot seem to figure out whether > the AUTOCOMMIT switch is a new feature on

currency of DATABASES = {'xx' : {'OPTIONS' = {'AUTOCOMMIT' ... flag.

I am confused by the documentation. I cannot seem to figure out whether the AUTOCOMMIT switch is a new feature on the way in, or an obsolete feature on the road to deprecation. I can easily add the feature to adodbapi, but should I do so or not? -- Vernon -- You received this message because

Re: Extending the DATABASES = {'xx': {'NAME': construct to carry additional information and / or virtual names

Thanks for the feedback. I have incorporated your suggestions into my design. There is nobody around here I can use for a design review, so, begging your forgiveness, I will have to do it here. Here is how I am setting up the prototype... 1) re-implement the argument signature of adodbapi so

Extending the DATABASES = {'xx': {'NAME': construct to carry additional information and / or virtual names

Dear Gurus: At the bottom of this text there will be a question. In order for you to provide a quality answer to the question, you need more information. Perhaps a lot more information. The next few paragraphs will attempt to provide that. They will also be an introduction to a couple of

Re: Moving database backends out of the core

My organization just hit a use case where we need MS-SQL support. I am jumping on board, so there are at least two of us who can do maintenance. I must say that I would prefer quasi-supported status (akin to admin and geodjango) rather than actually being in the core. I think it would be a

Re: MySQL, Django 1.6, Python3

This thread interacts with another current thread: the one about MS-SQL database support. As I mentioned there, adodbapi is capable of accessing any ODBC compliant data source. MySQL is one of those. adodbapi is Python 3 compliant, and I have been using MySQL databases from Python 3 for

Re: Moving database backends out of the core

On Friday, March 8, 2013 4:43:20 PM UTC-7, Florian Apolloner wrote: > > On Friday, March 8, 2013 3:35:53 PM UTC+1, Michael Manfre wrote: >> >> If we have MSSQL in core I'd really like to be able to talk with it from >> a Linux machine too, it would also make testing easier since we'd just need

Re: Moving database backends out of the core

[My reply is below, after the question... scan down. VDC] On Friday, March 8, 2013 7:33:27 AM UTC-7, Javier Guerra wrote: > > On Fri, Mar 8, 2013 at 4:25 AM, VernonCole <verno...@gmail.com> > wrote: > > People tend to think of ADO as only talking to Microsoft databases.

Re: Moving database backends out of the core

I would love to volunteer for the project of MSSQL support. It happens that django-mssql uses a fork of my adodbapi v2.1 code. I pulled those changes back into the main branch of adodbapi (and did a lot of useful refactoring thanks to the good work done on the fork) at version 2.3.

Re: Moving database backends out of the core

Huh?? I am running sqlite with GIS on my laptop right now. It wasn't THAT hard to install. Yes, the documentation could use some cleanup, but it got me through the tutorial okay and gives me a platform to learn GIS on. I really support the idea of sqlite and postgres in the core and moving

Will be % string formatting be preferred in the future, or will string.format() be moving in?

Dear Gurus: I am a regular lurker on this list, and I have accepted the invitation to use 1.5rc1 to help test it. My group is putting together a small (but very important, we think) application which will use some features of 1.5 and geodjango. I have also been reading the corresponding 1.5

Re: Python 3: should we apply unicode_literals everywhere?

That seems to me (in my dark status as a lurker here) to be a brilliant idea. It is already established practice to say something like: "version 1.n of django requires 2.m or later of Python". The practice then would change to: "version 1.n of django requires 2.m of Python or 3.3 or later". I

Re: Django-mssql with the dream of passing the test suite

I should mention that if you use pywin32 build 215 or newer, an appropriate version of adodbapi will already be included. You do not need to download it separately from sourceforge or PyPi unless you are running IronPython. Since pywin32 is already a dependency for django-mssql, you should be

Re: Django-mssql with the dream of passing the test suite

Micheal: I note that your code is using the Adam Vandenberg fork of adodbapi. I have rolled Adam's changes back into the main branch of adodbapi, so that django can have the advantages of numerous bug fixes, as well as the ability to run in Python3 and IronPython. I have attempted to make

Re: Python 3 and you

> One assumption of the strategy I outlined was the fact that Django is > as close to 3.X as possible. Django 1.4 will require Python 2.5 or > higher, but I'm not sure how quick we can do the jump to 2.6, which > is recommended by the Python porting docs [1]. > Don't confuse "recommended" with

Re: Timezone-aware storage of DateTime

On May 31, 7:23 am, Daniel Swarbrick wrote: > I can almost hear the collective sigh as this topic once again rears > up ;-) > Thanks for bringing it up. I lurk both here and on db-sig, and intend to use your well done research to once again attempt an update of the

Re: Dropping support for old Python versions in Django 1.4

Jython is also at release 2.5, so droppin ig 2.5 would be harmful to that implementation. CentOS will be the same as RHEL. On Feb 4, 11:26 am, John Anderson wrote: > On Feb 4, 2011, at 12:23 PM, Łukasz Rekucki wrote: > > > With Django 1.3 almost out, I would like to ask,

Re: python 3.x

ot;drop in" for modules which are being converted? That would keep everyone doing such patches on the same page. -- Vernon On Sep 7, 12:01 am, Russell Keith-Magee <russ...@keith-magee.com> wrote: > On Sun, Sep 5, 2010 at 5:05 PM, VernonCole <vernondc...@gmail.com> wrote: >

Re: python 3.x

"Once we're at a Django 2.6 minimum supported version, using 2to3 to maintain parallel implementations becomes a lot easier." As much as I admire Russ, and I do, I don't think that the above statement is correct. For a short time on the pywin32 team we tried to "maintain parallel

adodbapi 2.3.0 (the django version) released

I have just released a version of adodbapi which is intended specifically for django compatibility. It should be useful for four different projects: 1) accessing Microsoft SQL and/or Microsoft ACCESS (JET) databases. 2) running django on IronPython 3) converting django to Python 3 4) multi-db

Re: Process discussion: reboot

, and unlike svn it's popular > > for a good reason. > > However, hg is decent as well; whatever the django team chooses, as > > long as it's not cvs it can't really be worse than svn. > > > (bzr fan, personally, but I'd prefer it if django moved over to git) > > &

Re: Process discussion: reboot

Not to start a flame war --- but PLEASE! don't use git. I already have to use the other two leading DVCS's and all three are one too many. I personally prefer bazaar, but python itself and pywin32 are both committed to mercurial. I suspect that hg would be a better choice for most people. --

Re: Porting Django to Python 3

Having survived the update of pywin32 to python 3, let me say that both comments are correct: 1) you do NOT create a fork, you convert the existing code so that it will run through 2to3 2) it takes a LOT of hand refactoring of older 2.x code to get ready for 2to3. and, may I add: 3) it's worth the

Re: Porting Django to Python 3

Dave: Wonderful! I am presently working on a project to get adodbapi (http://sourceforge.net/projects/adodbapi) working in django. That may be important to you since it is one of few db interfaces which has a working python 3 version for Windows. Keep in touch. -- Vernon Cole On Jan 8, 11:25 

Re: Proposal for new field type: CompositeField

Let me give a hearty YES to this proposal. I have been told that a composite field, like this, is a violation of good database design, and that a 'true' relational database cannot have this feature. That is why the guy who designed the database I helped implement in 1982 did not call his design