On 12/03/16 11:47, Nathan Cox wrote:
I don't understand why this conversation has had to go on for this long.
The original post was in February of 2012, and it is now March of 2016.
That's four years of discussion that basically boils down to a couple of
purists insisting that their coding s
Funkybob (Curtis Maloney) implemented a multiline template tag patch nearly
two years ago. He asked for feedback a number of times and received none. I
think there's enough support here that if someone were to implement a
patch, it'd probably be accepted. Adding the same argument as to why
mult
I don't understand why this conversation has had to go on for this long.
The original post was in February of 2012, and it is now March of 2016.
That's four years of discussion that basically boils down to a couple of
purists insisting that their coding style is the only coding style, fits
ever
The slowness of progress on django-mssql is entirely my fault due to the
personal reasons I briefly mentioned during DUTH. Microsoft has offered
help and in my opinion seems very eager to start pushing pull requests, but
I haven't had the bandwidth to direct their efforts. I should have more
bandwi
Yes, I wonder if Microsoft abandoned the idea of providing engineering
resources to help out projects like django-mssql or if things are just
moving really slowly? I'm not aware of any follow up related to that idea
since Michael, Michiya, and I visited Microsoft in October.
On Wednesday, March
Right, I see the log entries. Good to know there's a way to log them, for
those who use sentry it will be even easier to notice this problem,
just ensure you're logging WARNING messages.
Thanks
Federico
On Friday, March 11, 2016 at 1:18:27 PM UTC+1, Tim Graham wrote:
>
> Yes, I think it's {% in
You can always have a y/N-question to limit these cases. Though, I think
this is a problem as it is right now too, because you can always do a typo.
/Joakim
Den fredag 11 mars 2016 kl. 14:06:42 UTC+1 skrev Markus Holtermann:
>
> Hi Joakim,
>
> thank you for your proposal.
>
> I don't think this
Hi Joakim,
thank you for your proposal.
I don't think this is a good idea because you can easily accidentally undo
too many migrations which would inevitably will result in data loss. You
don't have the data loss problem in Git as you can always recover by using
`git reflog` to go back and e.g
On 11 Mar 2016, at 10:28, Tore Lundqvist wrote:
> Given MySQL’s interesting approach to transactional integrity, you can call
> transaction.set_rollback(False) after a query that failed with an
> IntegrityError and keep going.
>
> You can't use set_rollback() outside an atomic block so that n
Hello!
Today if you just need to unmigrate the *n* migrations before the last one
you would
typically run `migrate --list` and then `migrate
` where
`migration_name` is the migration you want to roll back to.
To reduce the steps of this procedure i think it would be nice to introduce
a synta
Yes, I think it's {% include %} rendering an empty string if there's an
exception. In Django 1.9, we added a logger for these exceptions to make
debugging easier:
https://docs.djangoproject.com/en/stable/topics/logging/#django-template.
On Friday, March 11, 2016 at 6:30:35 AM UTC-5, Federico Ca
This never happened to me and I find it very strange. Maybe it's a bug or
maybe it's the intended behaviour, but I find it REALLY strange.
Consider a widget which, for some reason, raises an exception:
class CoolWidget(AdminTextareaWidget):
def render(self, name, value, attrs={}):
WR
> Specifically, could you try adding `self.needs_rollback = False` at the
> bottom of the `BaseDatabaseWrapper.rollback()` and tell me if that helps?
>
> Yes, this helps! With this change I can make it work without bypassing the
public API.
>
>
>
> On 07 Mar 2016, at 12:55, Tore Lundqvist >
13 matches
Mail list logo
