On 8 avr. 2013, at 10:21, VernonCole <vernondc...@gmail.com> wrote:
> 1) re-implement the argument signature of adodbapi so that it agrees with the
> recommendation for positional and keyword arguments in PEP 249, except that
> the first positional argument is called "connection_string" rather than
> "dsn". ((Also handle the case where "dsn" is defined but "connection_string"
> is not by using "dsn" as a default.)) The user may supply other keyword
> arguments not documented in PEP 249 -- for example "timeout".
>
> 2) permit the first positional argument to be a dictionary, which will be
> merged with **kwargs. This will make it easy to pass both the DATABASES
> dictionary and other keyword arguments in.
>
> 3) Look in the resulting merged dictionary for key "OPTIONS". If present,
> merge that dictionary into the existing keywords.
>
> 4) Django specifies that database connection keywords are UPPER CASE. Pep
> 249 specifies the same tokens in lower case. Therefore, go through the
> dictionary,
> creating lower case copies of any upper case keyword items (if they are not
> already defined.)
In my opinion, adodbapi should have an API that makes sense by itself,
regardless of Django.
Then the `get_connection_params` method of the database backend should take
care of mangling arguments to match that API.
Of course, that's bikeshedding: you write the software, you get to chose the
API that suits your tastes.
> 4) Create an adodbapi.remote module with the same signatures as adodbapi.
>
> 5) In the remote, use the dictionary keywords "'pyro_connection",
> "remote_proxy" and "remote_port" to connect to the server, supplying
> appropriate defaults.
>
> 6) Create adodbapi.server.py which will be a PyRO server daemon for adodbapi
> connections.
>
> 7) The remote client passes the entire connection keyword dictionary to the
> server. The remote or the server may add keywords and supply defaults.
>
> 8) The server will attempt an adodbapi.connect(*args, **kwargs) using the
> merged keyword dictionary.
>
> 9) Internally, adodbapi.connect will execute the equivalent of:
> connection_string = kwargs['connection_string'] % kwargs
> to allow the programmer to build her connection string by using Python
> "String Formatting Operations". She will place "%(keyword)s" constructs in
> her connection
> string where appropriate.
>
> 10) Dictionary keywords will be used for ADO option settings:
> ADO.Connection_timout = kwargs.get('timeout', 30)
Yes, overall, that design sounds reasonable.
It's similar to running PostgreSQL behind pg_pool (a connection pooler). As
long as Django connects to something that behaves like a database, it's all
right.
>From the point of view of Django, your PyRO server daemon will be the
>database, even though it's actually a proxy. Whether the proxy gets its
>parameters from its own configuration or from Django doesn't really matter.
>Just go for the most practical solution for your use case.
--
Aymeric.
--
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.
