MySQL specific feature. So I am sharing it now
here in its 37 lines of glory.
https://gist.github.com/matteius/fff39563d1d8ddfc7168
I am looking for general feedback as well as some specific feedback:
1.
Right now how I actually execute this custom logic is slightly ugly: I
check if the
So in Django 1.6, commit_manually() is deprecated and then removed in
Django 1.8.
I'm not sure I totally get the change to require everyone use atomic(), and
I'm not sure it is clear yet what changes I'll need to make to make to
convert the code to use atomic.
It does appear instead of doing
Thanks for your replies,
On Thursday, April 4, 2013 11:23:43 PM UTC-4, Matteius wrote:
>
>
> Greetings Developers,
>
> Today at work I fixed a thread safety issue in our code whereby two
> threads were calling get_or_create on the same URL which has a uniqueness
> constrai
Greetings Developers,
Today at work I fixed a thread safety issue in our code whereby two threads
were calling get_or_create on the same URL which has a uniqueness
constraint. It was in some cases raising an IntegrityError in sentry even
after I converted our atomically incorrect code to use
I agree on both this point and your future point about using a
migration tool such as South (and South is truly the only one I can
think of that will do this painlessly). We definitely suffer from
these User model problems at our Company as does everyone I think that
really uses Django's authentic
I just thought because I did surgery on my own neck once I'd be able
to go to the guilde of surgeons.
On Feb 16, 7:12 pm, Luke Plant wrote:
> On Wed, 2011-02-16 at 11:36 -0800, Matteius wrote:
> > OK got it down to 15 using another def queryset in the Assignment
> > admin
_user`.`username`,
`auth_user`.`first_name`, `auth_user`.`last_name`,
`auth_user`.`email`, `auth_user`.`password`, `auth_user`.`is_staff`,
`auth_user`.`is_active`, `auth_user`.`is_superuser`,
`auth_user`.`last_login`, `auth_user`.`date_joined` FROM `auth_user`
On Feb 16, 12:50 am, Matteius wrote:
>
a new Course's edit page now has all these as
inlines. Well if I have a course with 4 assignments and 1 instructor
thats 25 DB queries. We need a similar way to limit queries with
inline objects in the Django admin.
Sincerely,
Matteius
--
You received this message because you are subscri
Thanks, you got me going on the right path.
On Feb 14, 12:31 pm, Jacob Kaplan-Moss wrote:
> On Mon, Feb 14, 2011 at 11:41 AM, Matteius wrote:
> > No the hits are with the initial page load before any AJAX gets
> > called, my AJAX code is 2 DB hits. I am not claiming select_rel
Well and Django has really fixed many of my initial concerns, I really
want to go, there is a bunch of stuff I missed in Amsterdam the last
time I went in 2007. I would also like to give a presentation of
django-classcomm Http://classcomm.googlecode.com/ and http://classcomm.net/
as well as working
elect_related. If you are saying that django ORM should
> make select_related=True the default - no. That would be bad. Every
> query for a model with a foreign key would be bloated by the
> additional joins and selects, whether or not any of the data on the fk
> was being used.
I have a very small test database on my test development virtualbox
environment and so while I've been adding in custom AJAX for dynamic
ForeignKey filters (in the case of Enrollment's Assignment list) I
noticed that because I'm using the Django Debug Toolbar. Well on
these pages with only ~28 Enr
I want to optimize my json call and protect data by doing something
like:
assignments = Assignment.objects.values('id',
'name').filter(course=enrollment.course)
payload = serializers.serialize("json", assignments,
ensure_ascii=False)
But m
What I want to see (and possibly the closest I've seen it with was a
video on the django_command_extensions) is an interactive debugger
built into my test-dev server so I can have break pts, switch logic
values in place, etc. dynamically on the test-dev server.
-Matteius
On Feb 10, 1:
Russell hit the nail on the head with his initial reply. I don't have
time to read all the rest of this, but definitely and good luck on
your masters. Congratulations on getting into a program.
On Feb 10, 12:29 am, Russell Keith-Magee
wrote:
> On Thu, Feb 10, 2011 at 5:45 AM, Thomas Adamcik wr
Nevermind, it would seem as though transactions are only for rolling
back or preventing database changes in the case of failures, and
provide no other kind of constraints. I'm writing an article on
enforcing uniqueness constraints in Django.
On Feb 3, 1:19 am, Matteius wrote:
> Well
lock on the user/model to prevent duplicate
actions ...
On Feb 2, 10:21 pm, Matteius wrote:
> which I am guessing it is not ...
>
> On Feb 2, 4:57 pm, Alex Gaynor wrote:
>
>
>
> > On Wed, Feb 2, 2011 at 5:55 PM, Matteius wrote:
> > > If I have multiple requests h
which I am guessing it is not ...
On Feb 2, 4:57 pm, Alex Gaynor wrote:
> On Wed, Feb 2, 2011 at 5:55 PM, Matteius wrote:
> > If I have multiple requests hit the cache.add at the same time, is it
> > guaranteed that only one cache.add will return success (True) once and
> &g
If I have multiple requests hit the cache.add at the same time, is it
guaranteed that only one cache.add will return success (True) once and
all other requests are guaranteed to be failures, even in the case of
race conditions?
cache.add('add_Grade', 'Some Value')
--
You received this message be
e, Feb 1, 2011 at 12:12 AM, Horst Gutmann wrote:
> > On Mon, Jan 31, 2011 at 5:02 PM, Matteius wrote:
> >> I think it would be really useful to have a way (possibly a decorator
> >> such as @hide_setting) such as to protect deployed sites when they
> >> switch over t
I think it would be really useful to have a way (possibly a decorator
such as @hide_setting) such as to protect deployed sites when they
switch over to debug mode. To me this would be a most useful setting
to have, especially when protecting secret key settings. Please be
advised.
--
You receiv
21 matches
Mail list logo