Re: Search Refiner - Can anyone skype and help me?

[Asif Saifuddin]

Hi,

This group is for development of django itself/internals. for your problem 
please post to django-users mailing list.

Regards,

Asif

On Tuesday, January 26, 2016 at 8:43:27 AM UTC+6, eZ_Harry wrote:
>
> Hello,
>
> I have stuck making a search refiner for my website and have been stuck 
> for so long now, I am really just in need of some direction and to get 
> someone to tell me roughly how I should be going about it. If anyone could 
> help me that would be greatly appreciated. Just message me and ill send 
> over my skype. Cheers
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b9ca5cdb-d6cf-4a88-928c-f69e74fabad6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Refiner - Can anyone skype and help me?

[eZ_Harry]

Hello,

I have stuck making a search refiner for my website and have been stuck for 
so long now, I am really just in need of some direction and to get someone 
to tell me roughly how I should be going about it. If anyone could help me 
that would be greatly appreciated. Just message me and ill send over my 
skype. Cheers

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/01663778-09c7-4632-aff5-77c7de1b11b0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Improving MSSQL and Azure SQL support on Django

[Fabio Caritas Barrionuevo da Luz]

is there any update about the progress of this?

-- 
Fábio C. Barrionuevo da Luz
Palmas - Tocantins - Brasil - América do Sul



Em terça-feira, 13 de outubro de 2015 18:12:55 UTC-3, Tim Graham escreveu:
>
> If anyone is interested in listening in on the meetings with Microsoft 
> engineers (Wednesday and Thursday 9am-5pm Pacific), let me know and I'll 
> send you the Skype link.
>
> On Friday, October 2, 2015 at 11:53:17 AM UTC-7, Meet Bhagdev wrote:
>>
>>
>>
>> On Thursday, October 1, 2015 at 12:32:25 PM UTC-7, Tim Graham wrote:
>>>
>>> Hi Meet,
>>>
>>> I was wondering
>>>
>>> 1. If you have any progress updates since your last message?
>>>
>> 
>>
>> * Yes, engineers on my team I are currently ramping up on the three 
>> Django-SQL Server adapters*
>>
>>
>>- *  Django-pymssql*
>>- * Django-pyodbc-azure*
>>- 
>> * Django-mssql *
>>
>> * The goal is to have a thorough understanding of what’s good and 
>> what’s bad with these adapters before the event. *
>>
>>>
>>> 2. If you have any further details on the schedule for the time in 
>>> Seattle in a week and a half? (including video conference details for those 
>>> unable to attend in person)
>>>
>>
>>- *We will have a video conference link for Day 2 and Day 3. 
>>Participants interested can join the conference stream from their 
>> browser. 
>>The conference room mics are only capable to a certain extent. Thus the 
>>quality might be a little poor. *
>>
>>
>>- *We are finalizing the detailed schedule this week and will post it 
>>on this thread by next Friday.  *
>>
>>
>> 3. If myself or the other attendees should do anything to prepare for the 
>>> meetings?
>>>
>>> *Here are some things that you should prepare before coming to 
>> Seattle.*
>>
>> *-*
>>
>>
>>- 
>> * Have a clear understanding of the things that you need from 
>>Microsoft to improve the SQL Server support on Django. We have resources 
>> to 
>>do the heavy lifting but need guidance. *
>>- * Share with us the issues we can help fix (on the Django side 
>>and on the Django-ORM(database) side). *
>>
>>
>> Thanks!
>>>
>>> On Thursday, September 17, 2015 at 3:38:09 PM UTC-4, Tim Allen wrote:

 Hey team, as promised, here are the simple tests I put together to 
 benchmark pyodbc vs pymssql. Be kind, this was Python I wrote a long time 
 ago!

 https://github.com/FlipperPA/pyodbc-pymssql-tests

 I've included example output on the README. Very basic, but useful.

 On Wednesday, September 16, 2015 at 11:27:59 AM UTC-4, Tim Allen wrote:
>
> Thanks for all of your efforts, Aymeric, I've been following your 
> project since its inception - I'm FlipperPA on GitHub.
>
> On Sunday, September 13, 2015 at 4:59:34 AM UTC-4, Aymeric Augustin 
> wrote:
>>
>> Did you mean “pyodbc outperforms pymssql”? Or did you go with pyodbc 
>> despite lower performance? (Or did I misread that?)
>>
>
> We went with pyodbc, despite lower performance. I've been meaning to 
> put the simple tests up on GitHub - making a note to do that this week.
>
> At the time we were looking at options, we couldn't find a stable 
> Django option for pymssql. I should have been more clear about the time 
> frame in which we were testing as well; this was right around the time 
> that 
> you first started django-pymssql. 
>
>>
>>- django-pymssql is basically django-mssql on Linux. We could 
>>debate whether django-pyodbc-azure is more stable than django-mssql. 
>>There’ve been a bunch of forks over the years.
>>
>>
>> I’m not going to argue it further because I would inevitably sound 
>> like I’m tooting my own horn which isn’t my intent. I will just say that 
>> the picture isn’t all that clear.
>>
>
> There is definitely much more to consider now, than when we were first 
> assessing options. I will say I've been impressed with 
> django-pyodbc-azure 
> staying up to date with Django's releases.
>
> From the perspective of someone who works on Django’s internals, I 
>> believe django-pyodbc-azure could use a review of how the Django 
>> database 
>> backend API is implemented.
>>
>> For example, looking at the new transaction APIs I introduced in 1.6, 
>> I see that it commits or rolls back implicitly in _set_autocommit. 
>> At best that’s weird and useless, at worst a data corruption bug.
>>
>> Nothing that couldn’t be fixed, but just because the code works 
>> doesn’t means it handles edge cases well. django-mssql probably fares a 
>> bit 
>> better since its author cooperated with and eventually joined the core 
>> team.
>>
>> Thanks to the abstraction provided by the Python DB-API, it should be 
>> quite easy to port code implementing Django’s database 

Re: deadlock risk from using cache a load time

[John Bazik]

I got a patch from the django-cms folks that moves template loading into 
their AppConfig.ready() routine, but the problem persists.

The last few lines of apps.populate are:

self.models_ready = True

for app_config in self.get_app_configs():
app_config.ready()

self.ready = True

At this point, django has the lock, app_config.ready() invokes the ready 
code for my apps, and I'm back where I started (nested call to 
apps.populate and deadlock).

In db/models/base.py, in model_unpickle, I see this:

if isinstance(model_id, tuple):
if not apps.ready:
apps.populate(settings.INSTALLED_APPS)
model = apps.get_model(*model_id)

Can that test instead be "if not apps.models_ready"?  That would prevent 
the nested call and fix my problem.

John

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/26b0709d-5298-4707-9a42-b4c4e4529e76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: two levels of m2m relationship & update values

[Tim Graham]

Please write to django-users as this mailing list is for the development of 
Django itself.

On Monday, January 25, 2016 at 6:07:41 PM UTC-5, Slomski wrote:
>
> Hi,
>
> I am trying to create a django app as follow:
>
> a Block with unique name can have few Flats. Flat name in each Block is 
> unique but flat names can be the same in different Blocks and Flat name 
> needs to be chosen from the range {Paprika, Water, Banana}. 
> each Flat can have three rooms and room names are Blue, Red, Yellow.
> there can be some people staying for a night in each room and the number 
> of peoples can change daily.
>
> so, 
>
> you want to update number of people that stay in each room daily by either 
> selecting specific room or selecting multiple rooms so you can update 
> either one room or multiple rooms in one go.
>
> Question 1: 
>
> Am I right using right relationships: m2m with m2m relationship ? 
>
> Blocks have m2m relationships with Flat names
> Flat names have m2m relationship with Room names
>
> Questions 2:
>
> If relationships are correct than how can you update selected single or 
> multiple rooms via two levels of m2m relationship ? 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/67e01547-017a-4db0-89e2-861f6c68acff%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

two levels of m2m relationship & update values

[Slomski]

Hi,

I am trying to create a django app as follow:

a Block with unique name can have few Flats. Flat name in each Block is 
unique but flat names can be the same in different Blocks and Flat name 
needs to be chosen from the range {Paprika, Water, Banana}. 
each Flat can have three rooms and room names are Blue, Red, Yellow.
there can be some people staying for a night in each room and the number of 
peoples can change daily.

so, 

you want to update number of people that stay in each room daily by either 
selecting specific room or selecting multiple rooms so you can update 
either one room or multiple rooms in one go.

Question 1: 

Am I right using right relationships: m2m with m2m relationship ? 

Blocks have m2m relationships with Flat names
Flat names have m2m relationship with Room names

Questions 2:

If relationships are correct than how can you update selected single or 
multiple rooms via two levels of m2m relationship ? 

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7ab7e227-a573-41b1-bac7-812ae3b0c668%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

model formsets and recently stale data

[Tom]

We saw an unexpected result working with model formsets and recently stale 
data. 

Consider a simple Book model with soft deletion.

```
class Book(models.Model):
name = models.CharField(max_length=100)
deleted = models.BooleanField(default=False)
```

We have one book

```
book = Book.objects.create(name="Grapes of Wrath")
```

and a model formset to edit Books.

```
BookFormSet = modelformset_factory(Book, fields=('name',), max_num=None, 
extra=0)
```

A user initializes a formset to edit all non-deleted books. While that user 
is filling out the edit form, another user deletes the book.

```
# The user calls a view that initializes the formset. 
formset = BookFormSet(queryset=Book.objects.filter(deleted=False))
data = {
'form-TOTAL_FORMS': '1',
'form-INITIAL_FORMS': '1',
'form-MAX_NUM_FORMS': '',
'form-0-id': book.pk,
'form-0-name': "New Title"
}

# Before submission, another user deletes the book. 
book.deleted = True
book.save()

# Now the original user submits the form
formset = BookFormSet(data=data, 
queryset=Book.objects.filter(deleted=False))
formset.is_valid()  # True
formset.save()
```

Two Books now exist. Despite having `data['form-0-id'] = book.pk` and 
extra=0, django uses a ModelForm with instance=None, which ends up creating 
a new row. This is because BaseModelFormSet's _existing_object returns None 
if the submitted id is not in the queryset's set of ids. 
https://github.com/django/django/blob/master/django/forms/models.py#L573. 

Is this expected? If an id is submitted with a form, and that id isn't 
expected, could it make sense for formset validation to fail instead? 







-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/67d21f43-1da8-49af-8ad3-95042628fac6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: test --keepdb and explicitly migrating the test database

[Shai Berger]

Hi again,

On Monday 25 January 2016 18:33:15 charettes wrote:
> FWIW I've been working around this limitation by adding a suffix
> to my `DATABASES['alias']['TEST']['NAME']` setting if the project
> VCS branch is not the default one.
> 

What Marc said. That's nice, but doesn't  solve my problem.

On Monday 25 January 2016 15:02:08 Tim Graham wrote:
> Rather than a separate command option, I wonder if a syntax something like
> --database=default[test] might be interesting? Running any management
> command that already takes the --database option against a test database
> seems useful.
> 

Yes, I agree that would be better.

Shai.

Re: test --keepdb and explicitly migrating the test database

[Marc Tamlyn]

Simon - that's great but still means ending up having to create a new test
DB every time you switch to a new branch, something you do a lot if you're
part of the QA process!

+100 to this feature, it would be super useful for me, especially when
working with long running feature branches with migrations.

On 25 January 2016 at 16:33, charettes  wrote:

> FWIW I've been working around this limitation by adding a suffix
> to my `DATABASES['alias']['TEST']['NAME']` setting if the project
> VCS branch is not the default one.
>
> e.g. for Git
>
> import subprocess
>
> branch = subprocess.check_output(['git', 'rev-parse', '--abbrev-ref',
> 'HEAD']).strip()
>
> if branch != 'master':
> for alias in DATABASES:
> database = DATABASES[alias]
> name = database['NAME']
> test_name = database.setdefault('TEST', {}).setdefault('NAME',
> "test_%s" % name)
> database['TEST']['NAME'] = "%s_%s" % (test_name, branch)
>
> Simon
>
>
> Le lundi 25 janvier 2016 07:16:52 UTC-5, Shai Berger a écrit :
>>
>> Hi,
>>
>> While developing against a large project with many migrations, I found
>> 1.8's
>> --keepdb option to the test command a life-saver, changing the time to
>> run the
>> projects test from 7-8 minutes to under one (not even counting the tests
>> themselves). But it is still missing something.
>>
>> If I develop a branch which includes migrations, and -- these things
>> happen --
>> I need to change the migrations (whether because they had a bug, or
>> because I
>> rebased the branch and I need to resolve conflicts), I'm basically out of
>> luck
>> with --keepdb; there's no easy way to roll back migrations on the test
>> database (the only way would be to use a special settings file which
>> defines the
>> test database as a "production" one to roll the migrations back).
>>
>> I would like to have a "--test-db" option to the "migrate" command, which
>> lets
>> me run migrations explicitly against the test database, assuming it
>> exists
>> because of prior invocations of "test --keepdb" (and erroring out if it
>> doesn't, of course).
>>
>> Is it just me?
>>
>> Thanks,
>> Shai.
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/7ae240a4-3e21-43bd-a88f-dd75ba59810d%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMwjO1HKiMrhqi%3DQWCd_9GoYHKn3Bp52SQnTTW0OafK1msMzyA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: 'noescape' filter for django template

[Florian Apolloner]

And even then, |safe is exactly the same as |noescape

On Monday, January 25, 2016 at 4:33:01 PM UTC+1, Tim Graham wrote:
>
> Is there some reason you cannot mark the string safe in Python code using 
> one of the following methods? I think that's where escaping logic belongs.
>
>
> https://docs.djangoproject.com/en/stable/ref/utils/#django.utils.html.format_html
>
> https://docs.djangoproject.com/en/stable/ref/utils/#django.utils.safestring.mark_safe
>
> On Monday, January 25, 2016 at 10:12:17 AM UTC-5, Hangyu Zhang wrote:
>>
>> Hi All,
>>
>> I want to add a new filter names 'noescape'  to django template. After 
>> that,
>>
>> {{ |noescape }}
>>
>> will output the context variable without auto escape.
>>
>> It will be more convenient than
>>
>> {% autoescape off %}{{  }} {% endautoescape %}
>>
>> Thanks and regards,
>>
>> Hans
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e37949fd-a874-40e5-a0db-23907698204b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: test --keepdb and explicitly migrating the test database

[charettes]

FWIW I've been working around this limitation by adding a suffix
to my `DATABASES['alias']['TEST']['NAME']` setting if the project
VCS branch is not the default one.

e.g. for Git

import subprocess

branch = subprocess.check_output(['git', 'rev-parse', '--abbrev-ref', 
'HEAD']).strip()

if branch != 'master':
for alias in DATABASES:
database = DATABASES[alias]
name = database['NAME']
test_name = database.setdefault('TEST', {}).setdefault('NAME', 
"test_%s" % name)
database['TEST']['NAME'] = "%s_%s" % (test_name, branch)

Simon

Le lundi 25 janvier 2016 07:16:52 UTC-5, Shai Berger a écrit :
>
> Hi, 
>
> While developing against a large project with many migrations, I found 
> 1.8's 
> --keepdb option to the test command a life-saver, changing the time to run 
> the 
> projects test from 7-8 minutes to under one (not even counting the tests 
> themselves). But it is still missing something. 
>
> If I develop a branch which includes migrations, and -- these things 
> happen -- 
> I need to change the migrations (whether because they had a bug, or 
> because I 
> rebased the branch and I need to resolve conflicts), I'm basically out of 
> luck 
> with --keepdb; there's no easy way to roll back migrations on the test 
> database (the only way would be to use a special settings file which 
> defines the 
> test database as a "production" one to roll the migrations back). 
>
> I would like to have a "--test-db" option to the "migrate" command, which 
> lets 
> me run migrations explicitly against the test database, assuming it exists 
> because of prior invocations of "test --keepdb" (and erroring out if it 
> doesn't, of course). 
>
> Is it just me? 
>
> Thanks, 
> Shai. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7ae240a4-3e21-43bd-a88f-dd75ba59810d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: add prefered/default protocol in the sites framework #26079

[James Addison]

In using Marten Kenbeek's URL dispatch rewrite branch, I've found that
using the pattern of defining some site configuration in your settings is
the way to go: it more easily allows you to have URL patterns on multiple
domain/scheme combinations.

I use a dict similar to what Tim has shown, and then use it to initialize
my scheme/domain URL constraints in my root urls.py.
On Jan 25, 2016 08:01, "Tim Graham"  wrote:

> Oh, looks like django-hosts also has this problem. It looks like in some
> cases the URLs will be correct (due to the PARENT_HOST setting, I think,
> which is 'djangoproject.dev:8000' in the djangoproject.com dev settings),
> but if you are browsing a different host (e.g. the docs site), then those
> URLs use the value from the Site model.
>
> Another thought: I've sometimes thought that the Site model violates the
> principle that you shouldn't put configuration in your database. I guess
> there's some usefulness to having a ForeignKey to the site, but... would it
> be feasible to offer a SITES setting that could be used instead? e.g.
>
> SITES = {
> 1: {'scheme': 'http', 'domain': example.com, 'name': 'My Site'},
> ...
> }
>
> That would solve the portability issue, I think, since you could easily
> override the necessary parts in development settings. Not sure if it'd be
> palatable to deprecation the models though. I don't think maintaining both
> versions would be worthwhile in the long run.
>
> On Monday, January 25, 2016 at 9:57:39 AM UTC-5, Aymeric Augustin wrote:
>>
>> On 25 janv. 2016, at 14:19, Tim Graham  wrote:
>>
>>
>> I believe it's a common use case to import a copy of a production
>> database and examine it locally -- that's what I meant about portability.
>>
>>
>> I’m not convinced by this argument because the data for the Site model
>> will be wrong anyway in this situation. Or did I miss something?
>>
>> --
>> Aymeric.
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/b12433a7-aa49-4951-9a77-32747699038d%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALfx8k3fZev0ZOfUdKBq-74qSa6qu5n-O7pBTcLz9q7-25Sb%2BQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: add prefered/default protocol in the sites framework #26079

[Carl Meyer]

On 01/25/2016 09:01 AM, Tim Graham wrote:
> Oh, looks like django-hosts also has this problem. It looks like in some
> cases the URLs will be correct (due to the PARENT_HOST setting, I think,
> which is 'djangoproject.dev:8000' in the djangoproject.com dev
> settings), but if you are browsing a different host (e.g. the docs
> site), then those URLs use the value from the Site model.
> 
> Another thought: I've sometimes thought that the Site model violates the
> principle that you shouldn't put configuration in your database. I guess
> there's some usefulness to having a ForeignKey to the site, but... would
> it be feasible to offer a SITES setting that could be used instead? e.g.
> 
> SITES = {
> 1: {'scheme': 'http', 'domain': example.com, 'name': 'My Site'},
> ...
> }
> 
> That would solve the portability issue, I think, since you could easily
> override the necessary parts in development settings. Not sure if it'd
> be palatable to deprecation the models though. I don't think maintaining
> both versions would be worthwhile in the long run.

+1 to this, I've long felt that the Site model was an anti-pattern. I
don't know if it's worth deprecating and switching to a different
system, though; it'd be a relatively painful deprecation for those using
it, I would guess.

Carl

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/56A6473F.50203%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: add prefered/default protocol in the sites framework #26079

[Tim Graham]

Oh, looks like django-hosts also has this problem. It looks like in some 
cases the URLs will be correct (due to the PARENT_HOST setting, I think, 
which is 'djangoproject.dev:8000' in the djangoproject.com dev settings), 
but if you are browsing a different host (e.g. the docs site), then those 
URLs use the value from the Site model.

Another thought: I've sometimes thought that the Site model violates the 
principle that you shouldn't put configuration in your database. I guess 
there's some usefulness to having a ForeignKey to the site, but... would it 
be feasible to offer a SITES setting that could be used instead? e.g.

SITES = {
1: {'scheme': 'http', 'domain': example.com, 'name': 'My Site'},
...
}

That would solve the portability issue, I think, since you could easily 
override the necessary parts in development settings. Not sure if it'd be 
palatable to deprecation the models though. I don't think maintaining both 
versions would be worthwhile in the long run.

On Monday, January 25, 2016 at 9:57:39 AM UTC-5, Aymeric Augustin wrote:
>
> On 25 janv. 2016, at 14:19, Tim Graham  
> wrote:
>
>
> I believe it's a common use case to import a copy of a production database 
> and examine it locally -- that's what I meant about portability.
>
>
> I’m not convinced by this argument because the data for the Site model 
> will be wrong anyway in this situation. Or did I miss something?
>
> -- 
> Aymeric.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b12433a7-aa49-4951-9a77-32747699038d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: 'noescape' filter for django template

[Tim Graham]

Is there some reason you cannot mark the string safe in Python code using 
one of the following methods? I think that's where escaping logic belongs.

https://docs.djangoproject.com/en/stable/ref/utils/#django.utils.html.format_html
https://docs.djangoproject.com/en/stable/ref/utils/#django.utils.safestring.mark_safe

On Monday, January 25, 2016 at 10:12:17 AM UTC-5, Hangyu Zhang wrote:
>
> Hi All,
>
> I want to add a new filter names 'noescape'  to django template. After 
> that,
>
> {{ |noescape }}
>
> will output the context variable without auto escape.
>
> It will be more convenient than
>
> {% autoescape off %}{{  }} {% endautoescape %}
>
> Thanks and regards,
>
> Hans
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/cc4ee24d-9186-4398-80f9-2aa2cd52a564%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

'noescape' filter for django template

[Hangyu Zhang]

Hi All,

I want to add a new filter names 'noescape'  to django template. After that,

{{ |noescape }}

will output the context variable without auto escape.

It will be more convenient than

{% autoescape off %}{{  }} {% endautoescape %}

Thanks and regards,

Hans

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/197f7366-4454-4da6-b732-978c2599191f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: add prefered/default protocol in the sites framework #26079

[Aymeric Augustin]

> On 25 janv. 2016, at 14:19, Tim Graham  wrote:
> 
> I believe it's a common use case to import a copy of a production database 
> and examine it locally -- that's what I meant about portability.

I’m not convinced by this argument because the data for the Site model will be 
wrong anyway in this situation. Or did I miss something?

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/AD243A26-0ADA-4A7A-9568-DF2F3653FC95%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: add prefered/default protocol in the sites framework #26079

[Tim Graham]

I believe it's a common use case to import a copy of a production database 
and examine it locally -- that's what I meant about portability.

I'm not aware of any Django usage that involves serving protocols other 
than http(s). Is this a case you've come across?

On Monday, January 25, 2016 at 4:34:25 AM UTC-5, Eric Rouleau wrote:
>
>
>1. it's not necessarily about SSL, it can be for any protocol but SITE 
>dependent.
>2. and for the dev/prod , your data will be different anyway so you 
>put the preferred protocol accordingly to your setup.
>3. it's only for generating full URLs, not for internal links (ex: 
>sitemaps). 
>
> a settings option could work too for sure, but I think we have more 
> flexibility with the sites framework, and any time you need the protocol 
> it's to generate a full URL which also needs the domain name.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/28c72705-db21-484c-8b1a-80621a52b4b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: test --keepdb and explicitly migrating the test database

[Tim Graham]

I've made similar mistakes (corrupting the test database) while working on 
djangoproject.com. For that project, test database creation is quick enough 
that I just drop "--keepdb" and start fresh. I think this will usually be 
the simplest option for most users, but I don't see a reason not to support 
your proposal.

Rather than a separate command option, I wonder if a syntax something like 
--database=default[test] might be interesting? Running any management 
command that already takes the --database option against a test database 
seems useful.

On Monday, January 25, 2016 at 7:16:52 AM UTC-5, Shai Berger wrote:
>
> Hi, 
>
> While developing against a large project with many migrations, I found 
> 1.8's 
> --keepdb option to the test command a life-saver, changing the time to run 
> the 
> projects test from 7-8 minutes to under one (not even counting the tests 
> themselves). But it is still missing something. 
>
> If I develop a branch which includes migrations, and -- these things 
> happen -- 
> I need to change the migrations (whether because they had a bug, or 
> because I 
> rebased the branch and I need to resolve conflicts), I'm basically out of 
> luck 
> with --keepdb; there's no easy way to roll back migrations on the test 
> database (the only way would be to use a special settings file which 
> defines the 
> test database as a "production" one to roll the migrations back). 
>
> I would like to have a "--test-db" option to the "migrate" command, which 
> lets 
> me run migrations explicitly against the test database, assuming it exists 
> because of prior invocations of "test --keepdb" (and erroring out if it 
> doesn't, of course). 
>
> Is it just me? 
>
> Thanks, 
> Shai. 
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/1518cb58-4ab7-4c28-a158-4b46d3599bda%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

test --keepdb and explicitly migrating the test database

[Shai Berger]

Hi,

While developing against a large project with many migrations, I found 1.8's 
--keepdb option to the test command a life-saver, changing the time to run the 
projects test from 7-8 minutes to under one (not even counting the tests 
themselves). But it is still missing something.

If I develop a branch which includes migrations, and -- these things happen -- 
I need to change the migrations (whether because they had a bug, or because I 
rebased the branch and I need to resolve conflicts), I'm basically out of luck 
with --keepdb; there's no easy way to roll back migrations on the test 
database (the only way would be to use a special settings file which defines 
the 
test database as a "production" one to roll the migrations back).

I would like to have a "--test-db" option to the "migrate" command, which lets 
me run migrations explicitly against the test database, assuming it exists 
because of prior invocations of "test --keepdb" (and erroring out if it 
doesn't, of course).

Is it just me?

Thanks,
Shai.

Re: add prefered/default protocol in the sites framework #26079

[Eric Rouleau]

   
   1. it's not necessarily about SSL, it can be for any protocol but SITE 
   dependent.
   2. and for the dev/prod , your data will be different anyway so you put 
   the preferred protocol accordingly to your setup.
   3. it's only for generating full URLs, not for internal links (ex: 
   sitemaps). 

a settings option could work too for sure, but I think we have more 
flexibility with the sites framework, and any time you need the protocol 
it's to generate a full URL which also needs the domain name.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2d0a6998-e21d-4a56-8380-2cf1273e3f97%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: add prefered/default protocol in the sites framework #26079

[Daniel Chimeno]

Hi,

I think the same in the case of:

>
>1. It would make data less portable between development (where SSL is 
>often not in use) and production.
>
> So maybe  a settings option could work.


El miércoles, 13 de enero de 2016, 14:21:14 (UTC+1), Eric Rouleau escribió:
>
> Hi
>
> I've created a ticket to propose adding a preferred/default protocol in 
> the "sites" framework at https://code.djangoproject.com/ticket/26079
>
> tim suggested I bring this to the mailing list and said the following:
>
> I'm not immediately convinced that a database field is the way to go for a 
>> couple reasons:
>>
>>1. It would make data less portable between development (where SSL is 
>>often not in use) and production.
>>2. I'm not sure it's a common case that only some sites would use SSL 
>>but not others.
>>
>> A third-party library called django-hosts, which djangoproject.com uses, 
>> adds a setting called ​HOSTS_SCHEME 
>> 
>>  to 
>> solve this. I think there's been some discussion about merging at least 
>> parts of this library into core since it solves common problems.
>>
>> See also #10944  (we might 
>> close this ticket as a duplicate of that one) and #23829 
>>  (about customizing 
>> ping_google to allow https). I think the best course of action would be 
>> to consider this feedback and write to the DevelopersMailingList 
>>  with your 
>> proposal. Either solution of a new setting or a new database field need 
>> feedback from a wider audience. Thanks!
>>
>
>- actually I would say it is even more portable as you 
>would probably use different databases between dev and prod , meaning you 
>can have http in dev but https in prod
>- its not just for SSL but also maybe a it could be used with other 
>protocols/schemes such as dav, webcal, feed
>- third party libraries could now have a definitive way of generating 
>a full URL 
>
> what do you guys think?
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/7063ff52-e065-4193-b615-f70c5cf45f1e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: add prefered/default protocol in the sites framework #26079

[Eric Rouleau]

since no feedback has been given yet,   I will add that the change is just 
an addition (new feature)  meaning there is no breaking of code , it just 
provides a way to define a default protocol for a given SITE, and will 
ultimately default to http when none is specified

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" 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 https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/df5ea735-b41e-4197-96a8-2cb6333bf3de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.