>
> Are you sure?
> My (possibly flawed) understanding is that if you can make the change in
> a single transaction, no-one else can see what is happening until it is
> committed. Effectively that would be an instantaneous change.
> Depending on your data architecture you might need to make some
On 23/05/2019 3:30 am, Dan Davis wrote:
Sure - setting it up is easy. There are hard questions about
database mutations however. If you drop column bar from table Fubar,
then the old code is still querying for buth Fu and Bar:
SELECT id, fu, bar FROM fubar
On-premise, this is the
Sure - setting it up is easy. There are hard questions about database
mutations however. If you drop column bar from table Fubar, then the old
code is still querying for buth Fu and Bar:
SELECT id, fu, bar FROM fubar
On-premise, this is the case for maybe 10 seconds, tops. In the
Maybe also do a hash of the file so you can search the DB with the file
itself if necessary, but just a suggestion as I don't know your use cases.
On Thursday, May 2, 2019 at 10:40:32 AM UTC-5, dans...@gmail.com wrote:
>
> I've come around to your way of thinking now that I'm considering
>
ly-To: "django-users@googlegroups.com"
Date: Thursday, May 2, 2019 at 11:40 AM
To: Django users
Subject: Re: My developers have run amok
I've come around to your way of thinking now that I'm considering
django-storages and AWS deployments.
--
You received this message because you are subscribed
I've come around to your way of thinking now that I'm considering
django-storages and AWS deployments.
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
I am not sure I understand about the "size and synchronization" but I
assume that is to do with them not giving you adequate infrastructure.
I don't think the DB advice is in any way specific to Django - I'd make the
same recommendation regardless of the framework being adopted - but
obviously
Derek, it all depends on where you are. I'm \at a government agency. The
wait time to get an NFS directory (yup, really) where I can write my data
between multiple redundant web servers is weeks. After that, there are
size and synchronization issues. So, there are other reasons than table
Just because something can be done, does not mean it should be done.
I have always avoided putting large binary files into the DB - why?
Primarily because the information in them is "dead" - very hard to search
or filter, which rather defeats the point of using a DB. Rather leave them
on
For the group, the eventual culprit was not complicated. It is a model
with a BinaryField that holds a file's contents. The Django documentation
advises against this, but why? Well, on-premise with big-iron database
like Oracle, storing the file in the database is attractive. So, what's
This will likely do it - tracking as a django middleware, I suspect too
much will still be lazy:
https://pypi.org/project/wsgi-objgraph/
On Tue, Nov 6, 2018 at 6:39 PM Dan Davis wrote:
> I am less certain this is the problem now. It may simply be that my
> project is one of the larger on the
I am less certain this is the problem now. It may simply be that my
project is one of the larger on the server. I did a quick audit, and
although they are new to django, they either used connection.cursor() as a
context manager, or called close explicitly.
I will try to develop a middleware
oh boy... Good luck.
you can use connection.cursor() as a context manager, which will clean up
connections after it exits. You could grep the project for
connection.cursor and add the context manager.
how did none of the devs know to clean up after themselves, either with a
context manager
On Tuesday, November 6, 2018 at 2:32:52 PM UTC-5, Jason wrote:
>
> refactor to use the ORM for those bits? and implement a team styleguide
> that says no direct connections unless its proven to work better?
>
I'm looking to identify the memory consuming bits to allow refactor. Not
a bad
refactor to use the ORM for those bits? and implement a team styleguide
that says no direct connections unless its proven to work better?
--
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails
My developers, who have come from ColdFusion, are fond of this:
cursor = connection.cursor()
cursor.execute()
data = [r for r in cursor]
return render(request, some_template_name, {'data': data})
The problem with this is that the database cursor reference will be leaked.
How do I integrate
16 matches
Mail list logo
