Re: Django 1.5.1 released

[Josh Cartmell]

Thanks for the extra details Jacob.  I had a bit of time and thought
it was an interesting challenge so I created a Google Script based
twitter bot that tweets the title and links of everything posted to
the Django Announce Google group.

There may be bugs but so far it's working, you can check it out here:
https://twitter.com/djangoannounce

On Apr 3, 9:17 am, Jacob Kaplan-Moss  wrote:
> On Tue, Apr 2, 2013 at 11:02 PM, Russell Keith-Magee
>
>  wrote:
> > In short, no - Twitter isn't a particularly reliable source for updates.
> > Someone in the core team will usually tweet about the release, but since
> > it's hard to share logins to a single Twitter account, and the person who
> > owns Django's twitter account won't always be involved in formally cutting
> > the release, we sometimes drop the ball.
>
> Actually, in theory we've got hootsuite set up to automatically tweet
> stuff posted to the blog. However, in practice it seems to break, and
> it hasn't updated in about two weeks. I'm looking into fixing it, and
> we'll try to keep a better eye on it ferm here on out.
>
> But yeah, as Russ says -- the announce list is going to be the most
> reliable. The number of things that could break about the blog ->
> hootsuite -> twitter flow make it rather unreliable.
>
> Jacob

-- 
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: Extending the DATABASES = {'xx': {'NAME': construct to carry additional information and / or virtual names

[Aymeric Augustin]

Hi Vernon,

Here's my feedback. (It turns out to be quite similar to Michael's.)

> 1) Assume that a Proxy based connection will be acceptable for inclusion in 
> django?

It seems to me that a custom database backend could handle this:
- subclass an existing backend
- override the implementation of get_connection_params / get_new_connection / 
init_connection_state (on master; IIRC the API was different in 1.5)
- set it as your ENGINE.

The API of database backends is private, because there's a lot of refactoring 
in this area, and it tends to change at each minor version. But it isn't too 
difficult to keep up with the changes, especially if you override just a few 
methods and don't need to support multiple versions of Django with the same 
code.

Although imperfect, the concept of database backends is an abstraction that is 
known to work, and it looks like it provides a solution to your problem.

I couldn't extract from your email another general purpose abstraction useful 
with any database. Your proposals sound quite specific, and better handled by 
code than configuration.

> 2) Add more keys to the DATABASES entries as needed by different backends? 
> (e.g. "CONNECTION_STRING": "xxx", "PROXY_ADDRESS: "10.0.0.7")

Yes, a database backend can document that it accepts or even requires some 
specific settings. The Oracle backend already has a few such settings 
(TEST_CREATE, etc.)

> 3) Pass the DATABASES dictionary down-chain to the proxy? (so it gets the 
> USER & PORT items, etc. and can process them itself)

If the proxy is a custom database backend, this information is available in 
self.settings_dict.

> 4) Have the proxy have additional routing information so it can add its own 
> intellegence to the connection attempt?

If the proxy is a custom database backend, it can do anything.

> 5) (In some future time) have the backend feed back more information to the 
> core, such as "I am connected to an XYZ engine, switch to the XYZ dialect of 
> SQL'?


If I wanted to support connecting to various databases from Django through 
ODBC, I would write an ODBC mixin handling the connection to the database, and 
for each database I would create a custom backend inheriting Django's backend 
and the ODBC mixin.

I hope this helps; let me know if I missed something and you cannot achieve 
your goals with a custom database backend!

-- 
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.

Ticket #14019: SQLInsertCompiler.as_sql() failure

[Tobias McNulty]

Hi all,

I'm starting this thread in response to the recent closure as wontfix of Ticket
#14019 ,
"SQLInsertCompiler.as_sql() failure"

The original summary in the ticket from mlavin goes as follows: "I came
across a problem with SQLInsertCompiler.as_sql function while trying to get
a stacktrace printed on insert errors (using
django-db-log).
I found that the as_sql function has an implicit condition that execute_sql
must be called first because execute_sql sets the return_id attribute."

The two proposed fixes either (a) check to make sure return_id exists
before accessing it, or (b) initialize return_id in __init__ so as to avoid
any implicit conditions that it's already set.

While as stated in the ticket this is not a public API, Django does
publicly support writing 3rd party database backends, and implicit
conditions like this make it difficult to develop and debug 3rd party
backends as well as other 3rd party database logging packages when
something goes wrong.  As kmtracey stated in the most recent comment, it
would be a big help to the larger Django community if methods like this did
not completely blow up when used incorrectly, but instead allowed a more
useful traceback to be raised by the actual offending code.

On a more general level, initializing attributes in __init__() is not a bad
practice, and ensuring that calling str() on an object doesn't raise an
exception is generally helpful too.  Given these issues, I wouldn't be
surprised if applying this fix also avoided similar issues during the
future development of Django itself.  Internal or not, "as_sql" is a
relatively common method, so making it at least somewhat resilient would be
helpful both for Django itself and the broader community of 3rd party apps
and backends.

Thanks in advance for considering re-opening this ticket.

Best,
Tobias
-- 
Tobias McNulty, Managing Member
Caktus Consulting Group, LLC
http://www.caktusgroup.com

-- 
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.