Re: Testing multidb without inconsistency
On Feb 25, 9:24 am, Jeremy Dunck wrote:
> I have a master and a replica. In test, the TEST_MIRROR on the
> replica points to master. I make writes to master, then read from
> replica, then assert some numbers.
>
> def test_stuff(self):
> Foo.objects.using('master').create()
> number_received = do_expensive_computations()
> # Down in some guts somewhere else, a query is called like so:
> # Foo.objects.using('replica').count()
>
> And that number bubbles up eventually
> assertEqual(number_received, 1)
>
> And this fails because the master has written, but it's in a pending
> transaction (enforced by TestCase as a perf optimization).
>
> I'm not trying to test the consistency here, I'm just trying to test
> that that code over there is correctly aggregating previous data.
>
> I understand the usefulness of the TestCase perf, and I could use
> TransactionTestCase, but again, I'm not trying to test transactions.
> This will affect a bunch of my code (i.e. many of my tests would have
> to be TransactionTestCase).
>
> I'd like the TEST_MIRROR'd replica to have visibility to master
> writes. Right now, a new connection is opened for each alias. It
> seems to me that it would be appropriate to share the connection on
> TEST_MIRROR'd DBs. I can see that this would cause trouble if you
> *wanted* to test against the visibility window, though.
>
> What do people think might be a reasonable solution?
I think you really should use a transactional test case. The reason is
that before you do a commit, your writes really should not be visible.
Hiding this in testing could lead to hiding bugs.
If you want different behavior, you can create your own TestCase
subclass which fiddles with the django.db.connections dictionary in
class setup and teardown.
- Anssi
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Testing multidb without inconsistency
On Sat, Feb 25, 2012 at 2:13 AM, Anssi Kääriäinen wrote: > On Feb 25, 9:24 am, Jeremy Dunck wrote: >> I have a master and a replica. In test, the TEST_MIRROR on the >> replica points to master. I make writes to master, then read from >> replica, then assert some numbers. >> ... > I think you really should use a transactional test case. The reason is > that before you do a commit, your writes really should not be visible. > Hiding this in testing could lead to hiding bugs. Of course that is the case, but here the transaction is artificial - part of the runner, not of the code under test. All that using TransactionTestCase does is side-step the pending transaction, not model the code under test more accurately. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Newline stripping in templates: the dnl way
Hi,
On Saturday, February 25, 2012 5:27:43 AM UTC+1, Tai Lee wrote:
>
> Adding more symbols to existing tags (e.g. {^ for x in y ^} or {% for
> x in y -%}), multi-line comment tags that don't actually include a
> comment, and half baked comment tags (where the closing tag is
> assumed) are all going to make templates uglier, and harder to read.
>
"-" is only supposed to be used in some edge cases where it's really
important that you don't have whitespace, usually there is no reason to
care for whitespace at all -- so it shouldn't make templates that ugly if
you don't use it everywhere.
{% stripwhitespace on %} at the top of your template, followed by {% for
> x in y %}? I think the latter is far more readable.
>
Usually I don't want to strip everything, but just at one location.
> My ideal solution is not to add new ways to mark each individual
> template tag that should have surrounding white space stripped, but to
> simply enable the removal of lines that have only block tags and no
> actual content. 99% of the time this is the right thing to do, and we
> just need a deprecation path and new template tag so that template
> authors can opt-in to the new behaviour now.
>
And what about the other 1%, there are even cases where whitespace is
important ;) Either way, why is stripping whitespace the right thing to do?
Given my experience "I don't care if there is or not" is what's 99% true of
the time…
Cheers,
Florian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/lyV4D4i58I4J.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Testing multidb without inconsistency
On Feb 25, 10:31 am, Jeremy Dunck wrote: > On Sat, Feb 25, 2012 at 2:13 AM, Anssi Kääriäinen > > wrote: > > I think you really should use a transactional test case. The reason is > > that before you do a commit, your writes really should not be visible. > > Hiding this in testing could lead to hiding bugs. > > Of course that is the case, but here the transaction is artificial - > part of the runner, not of the code under test. All that using > TransactionTestCase does is side-step the pending transaction, not > model the code under test more accurately. It is hard for the runner to know if transactions matter or not. I can see that if you just want to read the slave to verify something written to the master then the transactions hinders you. On the other hand, if you test some part of your code which uses multiple databases, using a shared connection can lead to hidden bugs. For example a view could write to the master database, then return what is written from the slave database. If you share the connection it works, if not it will not work. The problem is that transactions _are_ allowed when using TestCase. They just do not do anything. So, the TestCase doesn't know if the transaction is artificial or not. If the transactional methods were error-raising instead of no-ops then the situation might be different. Even then, you are likely testing code that will be ran inside transaction even if the code itself doesn't explicitly start one. Again, hidden bugs is the result. One more reason: if you would change your database setup in a way that you are actually using proper master-slave database setup for testing you would get problems. For example you could do this in Jenkins integration tests where the more complex database setup and overhead isn't a big problem. Any tests which depended on connection sharing will fail in the integration server. - Anssi -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Newline stripping in templates: the dnl way
On Feb 25, 10:52 am, Florian Apolloner wrote:
> Hi,
>
> On Saturday, February 25, 2012 5:27:43 AM UTC+1, Tai Lee wrote:
>
> > Adding more symbols to existing tags (e.g. {^ for x in y ^} or {% for
> > x in y -%}), multi-line comment tags that don't actually include a
> > comment, and half baked comment tags (where the closing tag is
> > assumed) are all going to make templates uglier, and harder to read.
>
> "-" is only supposed to be used in some edge cases where it's really
> important that you don't have whitespace, usually there is no reason to
> care for whitespace at all -- so it shouldn't make templates that ugly if
> you don't use it everywhere.
>
> {% stripwhitespace on %} at the top of your template, followed by {% for
>
> > x in y %}? I think the latter is far more readable.
>
> Usually I don't want to strip everything, but just at one location.
>
> > My ideal solution is not to add new ways to mark each individual
> > template tag that should have surrounding white space stripped, but to
> > simply enable the removal of lines that have only block tags and no
> > actual content. 99% of the time this is the right thing to do, and we
> > just need a deprecation path and new template tag so that template
> > authors can opt-in to the new behaviour now.
>
> And what about the other 1%, there are even cases where whitespace is
> important ;) Either way, why is stripping whitespace the right thing to do?
> Given my experience "I don't care if there is or not" is what's 99% true of
> the time…
In most situations white space matters:
{{ user.lastname }} {{ user.firstname }}
- AnssiKääriäinen
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Revisiting multiline tags
*Not* +1 on this.
Using extensively Django since the beginning and had never felt the
need to break a tag on several lines. HTML does not meant to be
written like any programming language (80 cols and so on) and the
philosophy of the Django template language has never been to expose a
full-featured programming language into HTML files.
Not convinced about the readability arguments because I don't read
HTML (like I read Python code).
The BDFL has to be strong and conservative on that because we all know
where this could easily ends.
Anyway, it is possible to use a 3rd party template language with
Django, is it not ?
> Mainly for comments, since {# #} is far, far more readable than {% comment
> %}{% endcomment %} even with syntax highlighting,
Not for me. A comment block turns blue with Vim so they are both
equally readable. The purposes are differents.
We have to keep in mind that Django template are aimed to non-dev
folks. So the concice the better.
Have a nice w.e.
On Feb 24, 4:15 pm, Daniel Moisset wrote:
> On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor wrote:
>
> > Folks, you seem to have missed Russell's point. Even if 100 people +1 this,
> > it's meaningless. That's a tiny fraction of this mailing list's readership,
> > much less of the Django community at large. Django is the way it is
> > because, first and foremost, of taste. If you'd like to make an argument as
> > to *why* it's useful, that's useful, but we don't take polls.
>
> It's useful because it helps some templaets in some cases be more readable
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Newline stripping in templates: the dnl way
Hi,
On Saturday, February 25, 2012 10:04:21 AM UTC+1, Anssi Kääriäinen wrote:
>
> In most situations white space matters:
> {{ user.lastname }} {{ user.firstname }}
>
Right, but
"""
{{ user.lastname }}
{{ user.firstname }}
"""
would have produced exactly the same output in HTML, hence my statement
that you usually don't have to care about it that much. Eg, you need to
make sure that there is whitespace but it doesn't matter how much since
it's collapsed anyways (and outside of tags it doesn't matter at all…)
Cheers,
Florian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/5wPjxugvoPQJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Newline stripping in templates: the dnl way
On Feb 25, 12:04 pm, Florian Apolloner wrote:
> Hi,
>
> On Saturday, February 25, 2012 10:04:21 AM UTC+1, Anssi Kääriäinen wrote:
>
> > In most situations white space matters:
> > {{ user.lastname }} {{ user.firstname }}
>
> Right, but
> """
> {{ user.lastname }}
> {{ user.firstname }}
> """
> would have produced exactly the same output in HTML, hence my statement
> that you usually don't have to care about it that much. Eg, you need to
> make sure that there is whitespace but it doesn't matter how much since
> it's collapsed anyways (and outside of tags it doesn't matter at all…)
I was just illuminating why putting {% stripwhitespace on %} in the
beginning of the template might not be that great an idea. Even with
the line change between the first and lastname they would be
concatenated if all whitespace is stripped.
I think we agree on this issue. Maybe I should have quoted the
original poster of the idea instead...
- Anssi
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Newline stripping in templates: the dnl way
I think this discussion is focusing on template tags, not template
variables. Maybe even a subset of template tags (e.g. block level tagsif,
for, block, filter, etc). Template variables and inline tags (e.g. now)
shouldn't have white space stripped.
In 100% of cases I can think of I either wouldn't care (in HTML templates)
or I would want lines that only contain block level tags and no actual
content removed from the rendered output of the template.
The only time I would explicitly NOT want this to happen is when I have an
existing template where white space matters and it has been carefully
crafted to work around Django's white space issues. I think SmileyChris'
solution from the ticket is the way to go, but in a backwards compatible
way. Make it opt-in with a new template tag, similar to the way auto
escaping is handled, and optionally a deprecation path that will make this
the default eventually.
I don't think anyone has suggested stripping ALL white space around ALL
template tags, or even ANY template variables.
Cheers.
Tai.
On Saturday, 25 February 2012 21:04:26 UTC+11, Florian Apolloner wrote:
>
> Hi,
>
> On Saturday, February 25, 2012 10:04:21 AM UTC+1, Anssi Kääriäinen wrote:
>>
>> In most situations white space matters:
>> {{ user.lastname }} {{ user.firstname }}
>>
>
> Right, but
> """
> {{ user.lastname }}
> {{ user.firstname }}
> """
> would have produced exactly the same output in HTML, hence my statement
> that you usually don't have to care about it that much. Eg, you need to
> make sure that there is whitespace but it doesn't matter how much since
> it's collapsed anyways (and outside of tags it doesn't matter at all…)
>
> Cheers,
> Florian
>
On Saturday, 25 February 2012 21:04:26 UTC+11, Florian Apolloner wrote:
>
> Hi,
>
> On Saturday, February 25, 2012 10:04:21 AM UTC+1, Anssi Kääriäinen wrote:
>>
>> In most situations white space matters:
>> {{ user.lastname }} {{ user.firstname }}
>>
>
> Right, but
> """
> {{ user.lastname }}
> {{ user.firstname }}
> """
> would have produced exactly the same output in HTML, hence my statement
> that you usually don't have to care about it that much. Eg, you need to
> make sure that there is whitespace but it doesn't matter how much since
> it's collapsed anyways (and outside of tags it doesn't matter at all…)
>
> Cheers,
> Florian
>
On Saturday, 25 February 2012 21:04:26 UTC+11, Florian Apolloner wrote:
>
> Hi,
>
> On Saturday, February 25, 2012 10:04:21 AM UTC+1, Anssi Kääriäinen wrote:
>>
>> In most situations white space matters:
>> {{ user.lastname }} {{ user.firstname }}
>>
>
> Right, but
> """
> {{ user.lastname }}
> {{ user.firstname }}
> """
> would have produced exactly the same output in HTML, hence my statement
> that you usually don't have to care about it that much. Eg, you need to
> make sure that there is whitespace but it doesn't matter how much since
> it's collapsed anyways (and outside of tags it doesn't matter at all…)
>
> Cheers,
> Florian
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/aKbJjYcK4QIJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Newline stripping in templates: the dnl way
>
> foo bar {#
>> #}baz
>>
>>
>> You just made a strong argument against multiline tags: I wouldn't want
> to see them abused this way!
>
Ah, I fully expected to be shot down on "aesthetic" reasons. I still
think it's better to have some (maybe slightly ugly) way to do things than
no way and revelling in perceived beauty, and if it's as easy as the above,
well, then so be it.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/Z2boxNNRUbcJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Newline stripping in templates: the dnl way
Let me make sure I've got this right --- The situation being discussed is
not where whitespace is insignificant and can be stripped, but where
whitespace is important and you want to control the exact amount of it,
e.g. plain text emails. In this case, just using stripwhitespace is not
enough. Right?
On 25 February 2012 04:27, Tai Lee wrote:
> What's better about {% for x in y -%} or {^ for x in y ^} over {%
> stripwhitespace on %} at the top of your template, followed by {% for
> x in y %}? I think the latter is far more readable.
>
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Revisiting multiline tags
On 2/24/2012 11:55 PM, Yo-Yo Ma wrote: I'm -1 on this for s specific reason; If you need multiple lines for a tag, you're doing it wrong. import this This would be far more helpful feedback if you would take the examples of too-long tags presented in this thread, and show the "right" way to do it. --Ned. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: Revisiting multiline tags
While this would be a valid argument if Django templates only rendered
HTML, that is not the only thing it can be used to render. The original
poster gave a very good example of a text-based email. I could list lots of
other formats in which white space must be followed to even be useful (like
.CSV).
I have used Jinja2 on multiple occasions to render C code that needed to be
code reviewed. I did not want to have to sanitize the output to be
readable. I hadn't realized Django templating wouldn't have been usable for
this. I just didn't want to have to install Django and PIL.
On Sat, Feb 25, 2012 at 3:31 AM, Stan wrote:
> *Not* +1 on this.
>
> Using extensively Django since the beginning and had never felt the
> need to break a tag on several lines. HTML does not meant to be
> written like any programming language (80 cols and so on) and the
> philosophy of the Django template language has never been to expose a
> full-featured programming language into HTML files.
>
> Not convinced about the readability arguments because I don't read
> HTML (like I read Python code).
>
> The BDFL has to be strong and conservative on that because we all know
> where this could easily ends.
>
> Anyway, it is possible to use a 3rd party template language with
> Django, is it not ?
>
> > Mainly for comments, since {# #} is far, far more readable than {%
> comment
> > %}{% endcomment %} even with syntax highlighting,
>
> Not for me. A comment block turns blue with Vim so they are both
> equally readable. The purposes are differents.
>
> We have to keep in mind that Django template are aimed to non-dev
> folks. So the concice the better.
>
>
> Have a nice w.e.
>
>
> On Feb 24, 4:15 pm, Daniel Moisset wrote:
> > On Fri, Feb 24, 2012 at 12:12 PM, Alex Gaynor
> wrote:
> >
> > > Folks, you seem to have missed Russell's point. Even if 100 people +1
> this,
> > > it's meaningless. That's a tiny fraction of this mailing list's
> readership,
> > > much less of the Django community at large. Django is the way it is
> > > because, first and foremost, of taste. If you'd like to make an
> argument as
> > > to *why* it's useful, that's useful, but we don't take polls.
> >
> > It's useful because it helps some templaets in some cases be more
> readable
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To post to this group, send email to django-developers@googlegroups.com.
> To unsubscribe from this group, send email to
> django-developers+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
>
--
Joe & Anne Tennies
tenn...@gmail.com
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: Revisiting multiline tags
After Ned's message, I'm -0, because while I'm not fond of multi-line tags, I cannot offer a good alternative when it comes to multi-line "with" tags. On Feb 25, 6:48 pm, Ned Batchelder wrote: > On 2/24/2012 11:55 PM, Yo-Yo Ma wrote:> I'm -1 on this for s specific reason; > If you need multiple lines for a > > tag, you're doing it wrong. > > import this > > This would be far more helpful feedback if you would take the examples > of too-long tags presented in this thread, and show the "right" way to > do it. > > --Ned. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
