Re: Django Models

[RAVVE MAALIE]

Actually you can refer to one to many relation model.

Its like one user has multiple address
Or
One adress has multiple users.

In models file.
You can make changes.
Like
For 1 user multiple address
Eg:
Class User(models.Model):
User_name= models.Charfield()
Class address(models.Model):
Adre=model.ForeignKey(User, on_delete=models.CASCADE)




On Fri, Aug 9, 2019, 02:36 göktürk sığırtmaç  wrote:

> Hi, I'm developing app with django. I have users module. My database
> schema users table and address table. Address table have foreign key from
> users table. Now how can compose app architecture? Should i new module as
> address and i should put address model etc. or Should i write address table
> in users model? Does second choose violate single responsibility principle.
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/91e6ab67-868b-4f83-a2da-6a04646a97b0%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAAB4E736Xwbzfe-ypFxcsM2jhex-J%2BOUvqbsoYtr%2B01nm2NsxA%40mail.gmail.com.

Django Models

[göktürk sığırtmaç]

Hi, I'm developing app with django. I have users module. My database schema 
users table and address table. Address table have foreign key from users 
table. Now how can compose app architecture? Should i new module as address 
and i should put address model etc. or Should i write address table in 
users model? Does second choose violate single responsibility principle.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/91e6ab67-868b-4f83-a2da-6a04646a97b0%40googlegroups.com.

Re: Display labels for autocomplete fields

[Janez Kranjc]

I have also come across the need for this and would be willing to work on a 
pull request for this feature.

On Wednesday, August 7, 2019 at 3:43:43 AM UTC+2, bjw wrote:
>
> At present the admin autocomplete docs mention 
> `ModelAdmin.autocomplete_fields` and
> `ModelAdmin.search_fields` which are used to configure select2. There are 
> also options for overriding the queryset used.
>
> However there seems to be no way of specifyng what is shown in the 
> autocomplete... it just calls `__str__` on the objects returned.
>
> Would it be possible to add a `search_display_fields` on the relevant 
> ModelAdmin, alongside `search_fields` to customise the display in the form 
> select box? This could be either a model field or a callable on the model 
> or modeladmin.
>
> Cheers!
>
> bjw
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/2c699014-8362-4ddf-b786-a7fe9d164c2f%40googlegroups.com.

Re: Make Development More Accessible

[William Vincent]

I think the way Rails does it, aka with well-done newcomers guide 
(https://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html) is 
worth looking at, as Carlton notes. A bit more streamlined than the current 
Django How To Contribute Guides.

Incidentally, Carlton and I will be having a chat with DHH of Ruby on Rails 
fame in September for the DjangoChat podcast so if there are any questions 
we should pose to him on managing the Rails community, do pass along to us. 
Certainly I'll ask him about issue tracking!

On Thursday, August 8, 2019 at 3:08:39 PM UTC-4, Tim Graham wrote:
>
> Although I'm not engaged too much with Django development now, a big 
> drawback of moving to GitHub issues for me would be that I could no longer 
> do a Google search like "something something site:code.djangoproject.com". 
> I could pretty much always find the ticket I was looking for that way. 
> Maybe GitHub issue search would be just as good but I find Google results 
> (with a snippet from the page) more useful.
>
> Another migration consideration is that Trac tickets are formatted using a 
> different syntax than GitHub issues.
>
> A migration feels like weeks of work and it doesn't strike me as a "heck 
> yea!" improvement. There would probably be benefits and drawbacks. As 
> Carlton said, I think it's time that could be more usefully allocated.
>
> I wonder how putting issues on GitHub would increase engagement? Is it 
> that Trac isn't discoverable from GitHub? What if GitHub let us redirect 
> https://github.com/django/django/issues (with the "Issues" tab) to 
> code.djangoproject.com?
>
> On Thursday, August 8, 2019 at 4:48:14 AM UTC-4, Carlton Gibson wrote:
>>
>> Just on this point: 
>>
>> > I agree with Andrew Godwins statement on Django loosing many 
>> contributors over the years and being in largely maintenance mode. 
>>
>> First, I'm not sure Andrew actually said this. Rather I think he reported 
>> is a point raised. However...
>>
>> I hear this kind of thing said. It ties-in with the "Django is boring" 
>> trope, when that's not meant as a compliment. 
>>
>> I think it couldn't be further from the truth. 
>>
>> Yes, these ain't the wild west days of yore. (Granted)
>>
>> But Django has successfully transitioned (with large thanks to the effort 
>> Tim Graham put in as Fellow over that time) from young to mature and it 
>> still growing. 
>>
>> Even if you take out your favourite headline feature — don't say it :) — 
>> v3.0 is going to be an awesome release. 2.2 was too. And 2.1. And it's 
>> continuing forward. 
>>
>> I wish we'd drop negative self-talk. It lowers morale and isn't even 
>> correct. Django is in great shape, and only getting stronger. 
>>
>> Could we do with more contributors? Yes. So let's do what we can to make 
>> that better. 
>>
>> I think of the effort to move from Trac. Maybe it's worth it... But I 
>> think of the same effort spent improving djangoproject.com, and the How 
>> to contribute guides (I think Tobias said the Contributing docs are 
>> X-thousands of words—all great but not necessarily that approachable), and 
>> so on, and I wonder if it's the best ROI? (That's a genuinely open 
>> question: DRF uses GitHub issues I don't see it leading to any more 
>> engagement there...) 
>>
>> Go Django Go! 🙂
>>
>>
>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/ace34012-e5ac-4bbc-ad5b-d3fbac1a560a%40googlegroups.com.

Re: Make Development More Accessible

[Tim Graham]

Although I'm not engaged too much with Django development now, a big 
drawback of moving to GitHub issues for me would be that I could no longer 
do a Google search like "something something site:code.djangoproject.com". 
I could pretty much always find the ticket I was looking for that way. 
Maybe GitHub issue search would be just as good but I find Google results 
(with a snippet from the page) more useful.

Another migration consideration is that Trac tickets are formatted using a 
different syntax than GitHub issues.

A migration feels like weeks of work and it doesn't strike me as a "heck 
yea!" improvement. There would probably be benefits and drawbacks. As 
Carlton said, I think it's time that could be more usefully allocated.

I wonder how putting issues on GitHub would increase engagement? Is it that 
Trac isn't discoverable from GitHub? What if GitHub let us redirect 
https://github.com/django/django/issues (with the "Issues" tab) to 
code.djangoproject.com?

On Thursday, August 8, 2019 at 4:48:14 AM UTC-4, Carlton Gibson wrote:
>
> Just on this point: 
>
> > I agree with Andrew Godwins statement on Django loosing many 
> contributors over the years and being in largely maintenance mode. 
>
> First, I'm not sure Andrew actually said this. Rather I think he reported 
> is a point raised. However...
>
> I hear this kind of thing said. It ties-in with the "Django is boring" 
> trope, when that's not meant as a compliment. 
>
> I think it couldn't be further from the truth. 
>
> Yes, these ain't the wild west days of yore. (Granted)
>
> But Django has successfully transitioned (with large thanks to the effort 
> Tim Graham put in as Fellow over that time) from young to mature and it 
> still growing. 
>
> Even if you take out your favourite headline feature — don't say it :) — 
> v3.0 is going to be an awesome release. 2.2 was too. And 2.1. And it's 
> continuing forward. 
>
> I wish we'd drop negative self-talk. It lowers morale and isn't even 
> correct. Django is in great shape, and only getting stronger. 
>
> Could we do with more contributors? Yes. So let's do what we can to make 
> that better. 
>
> I think of the effort to move from Trac. Maybe it's worth it... But I 
> think of the same effort spent improving djangoproject.com, and the How 
> to contribute guides (I think Tobias said the Contributing docs are 
> X-thousands of words—all great but not necessarily that approachable), and 
> so on, and I wonder if it's the best ROI? (That's a genuinely open 
> question: DRF uses GitHub issues I don't see it leading to any more 
> engagement there...) 
>
> Go Django Go! 🙂
>
>
>
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/e2f79302-0afe-46bf-97f5-34b48ffc9fd9%40googlegroups.com.

Re: Ideas for a new DEP on long-term Django API compatibility

[Adam Johnson]

Pascal,

I have had a short reply sitting in draft status for a while but not found
the energy to read all of your posts.

I'd just like to chime in and echo the sentiment from Aymeric, Florian,
Luke, and Tim. I worked with Django for nearly 5 years before being
accepted onto the core team.

One of the main tasks I've done in my career has been upgrading Django - I
did a recent count and I've done it at least 10 times on major applications
(100k+ lines). Upgrading Django has always been easy in comparison with
other changes. The Django upgrade process is miles above other Python
packages, which often miss changelogs let alone use standardized
versioning. I've always found the backwards incompatible changes in Django
improve my project's code standards incrementally (as Luke said).

When reviewing features in Django I've normally erred towards putting
everything through the deprecation cycle only to discuss it with other
developers and decide it's not worth it. Practicality beats purity as Tim
says.

The relative stability of Django is one of the things that attracted me to
it and continues to keep me here, working on it and recommending it to
others.

On Tue, 6 Aug 2019 at 13:42, Tim Graham  wrote:

> Pascal, you can read about the reason for the action actions change on the
> ticket https://code.djangoproject.com/ticket/29917 ...and on this mailing
> list...
> https://groups.google.com/d/topic/django-developers/-OWoYL_zryM/discussion.
> I hesitate to link to things like that in the release notes because the
> discussions can be long and somewhat difficult to follow. Rather, as
> appropriate, I tried to include a short summary of the rationale for
> backwards incompatible changes in the release notes.
>
> In my years working on Django, I found it reasonable to occasionally make
> backwards incompatible changes if there's a consensus that a deprecation
> isn't feasible or worthwhile. Sometimes practicality beats purity, in my
> experience.
>
> Luke's experience and views parallel mine. I think the current deprecation
> cycle works well.
>
> On Tuesday, August 6, 2019 at 4:12:23 AM UTC-4, Pkl wrote:
>>
>> Hello Luke,
>>
>> thanks for your comments, mine are below
>>
>> On Thursday, August 1, 2019 at 10:34:22 AM UTC+2, Luke Plant wrote:
>>>
>>> Hi Pascal,
>>>
>>> I know this is a very late reply, but there have been some things going
>>> round my head that I thought I should get down.
>>>
>>> *First,* some positive changes I think we can make from your
>>> suggestions:
>>>
>>> 1. I think in our release notes, for breaking changes that might need
>>> some justification, we should link to the tickets and/or django-devs
>>> discussions behind them. Adding full reasoning in the notes themselves
>>> would likely bloat them far too much, but a link could be helpful for
>>> anything which is not obviously necessary.
>>>
>>
>> Yes documenting the rationale behind breaking changes, via a ticket link
>> or another medium, would be indeed a nice improvement.
>>
>>
>>> 2. We should change the wording in our API stability docs
>>> , which
>>> does indeed initially sound like a promise never to break working code that
>>> follows docs:
>>>
>>> Django promises API stability and forwards-compatibility since version
>>> 1.0.
>>>
>>> We do have this line later on:
>>>
>>> If, for some reason, an API declared stable must be removed or replaced,
>>> it will be declared deprecated but will remain in the API for at least two
>>> feature releases. Warnings will be issued when the deprecated method is
>>> called.
>>>
>>> But we do make changes at a rate faster than that document would make
>>> you think.
>>>
>>> I suggest that as a contrast to the existing text on that page, we also
>>> point out that we are continually improving Django, and have a
>>> "(eventually) one way to do it" policy regarding how we plan APIs, which
>>> means we will remove old things, while always providing better
>>> alternatives. I'm happy to write a patch for this.
>>>
>>
>> As you imagine, I'd rather have had a change in actual django policy,
>> rather than a doc update to reflect the current status; but it'd be better
>> than nothing. However, the second sentence "*If, for some reason, an API
>> declared stable must be removed or replaced, it will be declared deprecated
>> but will remain in the API for at least two feature releases*" is itself
>> still misleading, since at least one recent major breakage violates it
>> 
>> ; *A pronouncement of the core dev team would be needed here**: is this
>> behaviour change a procedure error? Or is it really the new policy, to
>> allow changes which create immediate silent errors, and prevent third-party
>> compatibility shims from getting implemented?*
>>
>> Having "only one obvious way to day it" is a useful and common commitment
>

Summary Re: Migrations: A bug or a feature needing documentation?

[Barry Johnson]

On Monday, August 5, 2019 at 4:55:24 PM UTC-5, Barry Johnson wrote:
>
> [ TL;DR: A migration may use a “replaces” list pointing to migrations that 
> don’t actually exist.  This undocumented technique cleanly solves a 
> recurring difficult migration problem.  We seek consensus on whether this 
> should become a documented feature or that it is an unexpected side effect 
> subject to change in the future. ]
>


Earlier this week, I posted a question about an undocumented behavior in 
the migration system, wondering if it should be formally documented and 
supported.  The use case relates to migration of a database from one branch 
of a project to another when there were different migrations created in 
both branches.  I believe this is a use case that the migration system was 
not (and is not) intended to solve, yet it seems to be a real-world problem.

Summary of responses: 

After discussion, I think that -our- future approach will be more 
procedural:  We'll deliberately create an empty migration *just before* 
forking a parallel branch that may require migrations, and will eventually 
require migrating tenants from that branch back to our mainline code.  We 
will then use that empty migration as a placeholder, and if necessary 
create one or more migrations that will replace the empty step to handle 
any parallel schema changes.  It might be wise to document this practice as 
a suggestion for others faced with this use case.

We will still have a case where multiple migrations would each indicate 
that they replace one of those empty migrations, perhaps caused by multiple 
schema changes being applied to the "patch" fork.  We've seen that behavior 
create apparent duplicate entries in the django_migrations database table. 
 But the migration system loads that table into a set containing (app, 
name) tuples, so the duplicate entries aren't hurting anything at present.

Furthermore, there is nothing that deliberately ties the list of previously 
applied migrations (that set of (app, name) tuples) back to migrations that 
exist.  Entries in the table for migrations that no longer exist are a side 
effect of the current squashing logic.  They can eventually cause the 
django_migrations table to contain many more rows than are necessary; 
perhaps it may be useful to have a migration tool or operation that clears 
out those obsolete records.  Or, as Markus has suggested, it may be wise to 
have the squashing process clean up after itself by removing "replaced" 
entries instead of leaving them behind.

I'll work up a documentation change PR that people can review and accept, 
modify or throw away.

Thank you!

baj
-
Barry Johnson



-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b7d694aa-735f-429f-aae6-d0b948925d27%40googlegroups.com.

Re: Ignoring accept_language in localization middleware based on prefixed URL patterns

[Janez Kranjc]

So regarding the implementation my proposal is this:

instead of checking if a prefixed url pattern exists, resolve the current
request path to a pattern and check if it is i18n prefixed

any idea how much of a performance hit that would be? Because right now
we're accessing a cached variable, which is super fast. With this
implementation there's a bit more work that the server needs to do in the
middleware. The problem is that URL resolving takes place after the
middleware so even resolver_match is not yet available when we need it. Any
suggestions?

On Wed, 7 Aug 2019 at 09:51, Janez Kranjc  wrote:

> Another problem that is specific to APIs (which are not really the point
> here, just an example) is that using prefixed URLs that has the default
> language also prefixed - prefixing API urls during the lifetime of the
> application would break the API for specific users because the previous
> URLs would 302 to new URLs and all POST requests would break. But like I
> said - an API is just an example I'm using to illustrate my problem. Could
> be any part of an application.
>
> On Wed, 7 Aug 2019 at 09:20, Janez Kranjc  wrote:
>
>> Nothing prevents the change to the API endpoint except the fact that
>> users are actively using the API already and (it is my opinion) that a
>> change in another part of the application - like a sales page - shouldn't
>> affect the working of an unrelated part of the project. Also that would
>> mean refactoring the front-end code which uses API endpoint to use
>> different URLs instead of just adding a header.
>>
>> Imagine that I have a third party app and I include its URLs and they
>> have prefixed URLs (unlikely but could happen) - this would force me to
>> change the way my URLs work in order to have a multilingual API.
>>
>> On Wed, 7 Aug 2019 at 09:13, Aldian Fazrihady  wrote:
>>
>>> What prevents the change to the API endpoints so it will have language
>>> prefix as well?
>>>
>>> On Wed, Aug 7, 2019 at 1:56 PM Aymeric Augustin <
>>> aymeric.augus...@polytechnique.org> wrote:
>>>
 Hello,

 Yes, I think this change makes sense, assuming no unexpected
 difficulties arise in the implementation.

 Best regards,

 --
 Aymeric.



 On 6 Aug 2019, at 10:58, Janez Kranjc  wrote:

 Hi guys! I’m Janez Kranjc, I’ve been using Django for a bit now - since
 1.3 and I’ve recently come across and issue that’s been bothering me in
 multiple projects that I’m working on.

 Localization middleware ignores the accept language header if ANY url
 pattern exists that is i18n prefixed regardless of the current URL of the
 request.

 So the problem is the following: I have some URLs that are prefixed,
 and a lot that are not (such as all of the API endpoints). I sometimes need
 to return some translated strings in the API as well and for that I rely on
 the accept-language header. However in the middleware it is ignored because
 an unrelated part of the project has an i18n prefixed url pattern.

 Another way to look at the problem is this:

 Let’s say I have a SPA that uses i18n on its API endpoints and you rely
 on accept-language to serve the responses in the correct locale. I then
 decide to add a new app to your django project - a sales page. Instead of
 relying on accept-language I wish to have i18n prefixed URLs (maybe for SEO
 reasons or whatever). Suddenly the behaviour of the API changes even though
 I’ve made changes to an entirely different part of the project.

 Would it not make more sense for the middleware to check if the current
 URL pattern (the one that the request URL resolves to) is prefixed or not.

 The way I see it, this should be changed:

 i18n_patterns_used, prefixed_default_language =
 is_language_prefix_patterns_used(urlconf)

 Instead of checking the entire urlconf it should only check the current
 request URL and see if it resolves to a pattern that is i18n prefixed.

 To get around this I need to use a custom localization firmware in a
 lot of my projects. I would like to hear the devs’ opinion regarding this.

 --
 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 view this discussion on the web visit
 https://groups.google.com/d/msgid/django-developers/1b315c0b-9200-417b-816a-dd3c3b90ec67%40googlegroups.com
 
 .


 --
 You received this message because you are subscribed to the Google
 Groups "Django developers (Contributions to Django itself)" gro

Re: Migrations: A bug or a feature needing documentation?

[Barry Johnson]

On Wednesday, August 7, 2019 at 9:22:27 PM UTC-5, Markus Holtermann wrote:
>
> Let's look at the last question first, regarding duplicate entries in the 
> django_migrations table: Yes, this is to be a bug. At least how it's 
> currently used.
>

Agreed.
 

> Let's say you have migration foo.0001_initial and apply it. You then have 
> (foo, 
> 0001_initial) in the django_migrations table. You now create migration 
> foo.0002_something and also add a squashed migration 
> foo.0001_initial_squashed_0002_something. When you now run migrate, 
> Django will apply foo.0002_something and your database will have (foo, 
> 0001_initial), (foo, 0002_something) as well as (foo, 
> 0001_initial_squashed_0002_something).
> So far so good. That's all as expected. If you now remove foo.0001_initial 
> and foo.0002_something from your filesystem and remove the replaces 
> section in foo.0001_initial_squashed_0002_something it is as if Django 
> never new about foo.0001_initial or foo.0002_something. You can add new 
> migrations, everything works the way it should. However, if you were to add 
> e.g. foo.0002_something again, Django would treat it as already applied, 
> despite it being somewhere later in your migration graph.
> At this point, I don't think this is the intended behavior. That said, I'm 
> inclined to say that applying a squashed migration should "unrecord" all 
> migrations it replaces. I've not yet thought too much about the "fallout" 
> (backwards compatibility, 
>
rollback of migrations, ...). But at least with regards to migrating 
> forwards, this seems to be the right behavior.
>

To date, the migration system has been remarkably tolerant of spurious 
entries in the django_migrations table, and the squashing process (to date) 
does indeed leave breadcrumbs of since-deleted migrations behind.  Agree 
completely with your point about adding a subsequent migration with a name 
that exactly matches a previously created migration that has been removed. 
 For all practical purposes, the migration names should be unique over 
time, or the developer should ensure that the second incarnation of that 
name is a functional replacement.

We have, in the past, replaced the contents of the "0001_initial" migration 
in most of our apps, but it is incumbent on us to make sure that's correct.

Regarding your second point around "replaces" and merging migrations: I 
> think this will lead to inconsistencies in your migration order, thus 
> potentially causing trouble down the line. [...]  I suspect that two data 
> migrations could easily conflict or result in inconsistent data if applied 
> in the wrong order. For example, one data migration adding new records to a 
> table, and another one ensuring that all values in a column are in upper 
> case. If you apply both migrations in that order (insert and then ensure 
> uppercase) you can be certain that all values will be uppercase. If you, 
> however, first ensure uppercase and then insert additional values, you need 
> to make sure that the data in the second migration is properly formatted.
>

Oh, certainly agree, Markus, about the dangers of replacing migrations. 
 That's true across the board, even in the documented use cases.  The 
replacement steps MUST properly account for elidable data migrations.  

In the normal use case (the typical migration squashing process), the 
replacement step truly replaces the original step, and is executed at that 
original spot within the dependency graph.  (It can seem as if that 
replacement is moved "back in time", as if history were rewritten.  That 
means that any migrations subsequent to the original step will remain 
subsequent to the replacement, which works.

In the use case where the original does not exist, the replacement step 
remains where it is in the dependency graph.  It must, because there's 
nowhere earlier that it could be placed.  Could this introduce an 
inconsistency, especially with data migrations?  Yes, if the developer is 
not careful.  Using your example of an insertion of lowercase data followed 
by a conversion to uppercase data:  in one branch the insertion happens 
first; in a different branch (where the insertion is run as a replacement 
step) they could be run in a different order.  That would indeed appear to 
be one of the dangers of moving a database from one branch of code to 
another, and that (as things are today) the developer must understand the 
migration paths.

Hmmm.

Keeping all this in mind, I'm beginning to believe there is a procedural 
method to solve the parallel-development problem.  Just before creating a 
long-lived branch (such as as production release that may get patches), 
create an empty migration step in all apps.  Later, if patch migrations had 
become necessary in that branch, the mainline trunk can "replace" the empty 
step with an equivalent migration that replaces it.  At least, that will 
give us an order of execution that more closely resembles what the 
product

Re: Migrations: A bug or a feature needing documentation?

[Barry Johnson]

On Wednesday, August 7, 2019 at 2:17:45 PM UTC-5, Adam Johnson wrote:
>
> Some questions: Have you looked into the migration framework internals? 
> Are there any comments around "replaces" that indicate this behaviour? And 
> is there maybe a way of hooking into the migration planner, or adding the 
> ability, to support your use case without relying on the current 
> bug-feature?
>

[Looks quick...]  Interesting!  
There are two subtle points in the source that show the author 
intentionally planned for this case, both in a method named 
"remove_replaced_nodes()" that, ahem, removes the replaced migration nodes 
from the dependency graph if the conditions are right for replacement.  The 
docstring for that method begins with the sentence "Remove each of the 
'replaced' nodes (when they exist)."  And within the main loop of that 
method, the code does a "pop" to remove the replaced node, deliberately not 
failing if that replaced node does not appear in the graph:
 replaced_node = self.node_map.pop(replaced_key, None)
 if replaced_node:
  

The purpose of this particular method is two-fold:  It removes the replaced 
node, yes, but just as importantly it rewires the dependencies to and of 
this replaced node.  Any children of the replaced node now become children 
of the replacement, and any parents that point at the replaced now become 
parents of the replacement.

So deliberate use of this approach does require careful understanding of 
the dependency tree (which really isn't a surprise).

Interesting.


 

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/b6e576b9-ebbd-4263-8dd3-ae6ec79ced54%40googlegroups.com.

Re: Expand the Scope of Pluggable Secret Keys Ticket

[Adam Johnson]

This should be a separate ticket.

I'm not sure what you need for DB credential rotation - this can already be
done by creating a second user in your database, then changing Django's
config to use the new one, then deleting the old one.

On Thu, 8 Aug 2019 at 02:43, John Gooding  wrote:

> Would it be possible to expand the scope of the recently accepted secret
> key rotation ticket to include the ability to live rotate other credentials
> as well, such as the DB credentials?
>
> Or would this be a separate thing all together?
>
>
> https://groups.google.com/forum/#!searchin/django-developers/secret$20keys%7Csort:date/django-developers/jg-eu3HtLHI/V_rbzYKfAQAJ
>
> https://code.djangoproject.com/ticket/30360
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/4271925d-6198-4847-80a1-fe453a6e4313%40googlegroups.com
> 
> .
>


-- 
Adam

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM1cyxyZBexL1mp_cmis-SWPRqgRORMWV6%2Bfq%3DtmjLo93g%40mail.gmail.com.

Re: Expand the Scope of Pluggable Secret Keys Ticket

[Carlton Gibson]

Hi John, 

I'm inclined towards "separate thing all together". Maybe they're all 
related but the bigger a ticket gets the less chance it has of actually 
appearing... 

> ... DB credentials...

Let's say you put those in environment variables... Don't you just relaunch 
with a new environment to "rotate"? i.e. What special handling would Django 
need to provide?

Kind Regards,

Carlton


On Thursday, 8 August 2019 03:43:49 UTC+2, John Gooding wrote:
>
> Would it be possible to expand the scope of the recently accepted secret 
> key rotation ticket to include the ability to live rotate other credentials 
> as well, such as the DB credentials?
>
> Or would this be a separate thing all together? 
>
>
> https://groups.google.com/forum/#!searchin/django-developers/secret$20keys%7Csort:date/django-developers/jg-eu3HtLHI/V_rbzYKfAQAJ
>
> https://code.djangoproject.com/ticket/30360
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/42ac8575-415b-4b5a-a687-d23ca72ec305%40googlegroups.com.

Re: Make Development More Accessible

[Carlton Gibson]

Just on this point: 

> I agree with Andrew Godwins statement on Django loosing many contributors 
over the years and being in largely maintenance mode. 

First, I'm not sure Andrew actually said this. Rather I think he reported 
is a point raised. However...

I hear this kind of thing said. It ties-in with the "Django is boring" 
trope, when that's not meant as a compliment. 

I think it couldn't be further from the truth. 

Yes, these ain't the wild west days of yore. (Granted)

But Django has successfully transitioned (with large thanks to the effort 
Tim Graham put in as Fellow over that time) from young to mature and it 
still growing. 

Even if you take out your favourite headline feature — don't say it :) — 
v3.0 is going to be an awesome release. 2.2 was too. And 2.1. And it's 
continuing forward. 

I wish we'd drop negative self-talk. It lowers morale and isn't even 
correct. Django is in great shape, and only getting stronger. 

Could we do with more contributors? Yes. So let's do what we can to make 
that better. 

I think of the effort to move from Trac. Maybe it's worth it... But I think 
of the same effort spent improving djangoproject.com, and the How to 
contribute guides (I think Tobias said the Contributing docs are 
X-thousands of words—all great but not necessarily that approachable), and 
so on, and I wonder if it's the best ROI? (That's a genuinely open 
question: DRF uses GitHub issues I don't see it leading to any more 
engagement there...) 

Go Django Go! 🙂



-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/c27f0492-97a2-490e-b950-93ecd38b4008%40googlegroups.com.