noinput option for testing

[Daryl]

Hi All,

When running tests I often end up crashing things and when restarting
the tests i get the line;

Creating test database for alias 'default'...
Got an error creating the test database: (1007, "Can't create database
'test_x'; database exists")
Type 'yes' if you would like to try deleting the test database
'test_x', or 'no' to cancel:

So i type 'yes' and finish the tests, then i spend an hour searching
django.org to find the flag needed to suppress this message.

Would other developers support the suggestion that the lines below in
test/util.py be changed to add a helpful little line as suggested
below???


confirm = raw_input("Type 'yes' if you would like to try deleting the
test database '%s', or 'no' to cancel: " % TEST_DATABASE_NAME)

print "To auto-answer 'yes' to the following question, start your test
runner with the flag ' --noinput' "
confirm = raw_input("Type 'yes' if you would like to try deleting the
test database '%s', or 'no' to cancel: " % TEST_DATABASE_NAME)


Regards,

D

-- 
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: Anyone have ideas on #16550 - custom SQL before/after syncdb?

[Daryl]

On May 16, 2013 1:01 PM, "Jacob Kaplan-Moss"  wrote:

> Hi folks --
>
> Does anyone have some clever thoughts on how to solve #16650?
>
> https://code.djangoproject.com/ticket/16550#comment:7 is a good
> summary of the problem: if you're using extensions, you need a way to
> run some custom SQL in tests after the DB gets created by the test
> harness but before syncdb runs.
>
> The current patch and suggested solution on the ticket won't work (see
> the thread), but I think it's a legit need and I'd like to come up
> with a good solution and possibly reopen the ticket.
>
> Jacob
>
> Jacob, going back a couple of levels, if its true that;
- sqlite creates the db for you, and the testdb is created for you
- sqlite could be considered to set permissions for you (ie set the owner
of the db file)
- mysql does *not* create the db, but the testdb *is* created for you
- mysql requires you to issue a "grant all priv on..." on the db, but not
the testdb
- i have no idea about postgresql or oracle.
and ...
- the various db backends know how to craft db specific DDL
then...
- would it be logical for the db backend to create the db for you *if* it
doesn't already exist.

If the above are true, then why can't the same code that creates the testdb
also create the db if it doesn't exist, and that would be the logical place
to hook any post-create-db code such as user-defined data types etc?


This would/could also nullify some questions that new users have when they
get tangled up at the syncdb point of the tutorial if they have not granted
their usercode (from settings) access to the db.

D

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" 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 http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Re: sys.exit(1) from makemigrations if no changes found

[Daryl]

I'm +1 on being able to continue using the line
./manage.py makemigrations && ./manage.py migrate

I can't see many (any?) situation where someone *wouldn't* run
makemigrations & migrate as one logical operation, whether by typing
the commands or running a script.
What would the workflow be where you would make migrations but not apply them?

D



On 30 October 2014 12:29, Tim Heap  wrote:
> The backwards compatibility issue I was thinking of is for people using
> `makemigrations` in a script currently, expecting it to exit with 0 unless
> something very wrong has happened. For example, if `makemigrations` is run
> in a bash script with `set -e`, and it does not find any migrations, that
> script will then exit. Alternately, if someone is using a one-liner like
> `./manage.py makemigrations && ./manage.py migrate && another command` the
> makemigrations command will cause the whole command to abort early, even
> though no 'error' as such has happened. Backwards compatibility aside, this
> would be awkward to work around in scripts without simply ignoring the exit
> code of `makemigrations` completely, which then ignores legitimate errors.
>
> I have made a patch that calls `sys.exit(1)` when no changes are found, and
> made a pull request at https://github.com/django/django/pull/3441
>
> Tim
>

-- 
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 http://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CALzH9qsJ-qgPxGzmeMF3Lt9oXsn-eRk%3DUSNS%2BxZmbaKinMA2ww%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: GSoC 2020 Proposal for ModelStates in Migrations

[Daryl]

; Feedback and criticism is highly appreciated.
>>>>>>>>>>>
>>>>>>>>>>> Thanks!
>>>>>>>>>>> Kind regards
>>>>>>>>>>> Sanskar
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> 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-d...@googlegroups.com.
>>>>>>>>>> To view this discussion on the web visit
>>>>>>>>>> https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.com
>>>>>>>>>> <https://groups.google.com/d/msgid/django-developers/8e9a5959-d677-456f-9bb8-953e68162562%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>>>>> .
>>>>>>>>>>
>>>>>>>>> --
>>>>>>> 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-d...@googlegroups.com.
>>>>>>> To view this discussion on the web visit
>>>>>>> https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.com
>>>>>>> <https://groups.google.com/d/msgid/django-developers/fbf6ba88-2adc-4dd7-ac82-ecea6d1be313%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>>>> .
>>>>>>>
>>>>>> --
>>>>> 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-d...@googlegroups.com.
>>>>> To view this discussion on the web visit
>>>>> https://groups.google.com/d/msgid/django-developers/3b9516a5-3c0e-4707-b142-1eb8e091168b%40googlegroups.com
>>>>> <https://groups.google.com/d/msgid/django-developers/3b9516a5-3c0e-4707-b142-1eb8e091168b%40googlegroups.com?utm_medium=email&utm_source=footer>
>>>>> .
>>>>>
>>>> --
>>> 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/668c02b4-8a27-43fd-b449-53121d8e3a73%40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-developers/668c02b4-8a27-43fd-b449-53121d8e3a73%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>>
>> --
> 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/CACzaa%3DEn1uS9dwv4A%2Bbj9c4y4o4%2BWG0y3NCBNsZb_nAbYJFfMQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CACzaa%3DEn1uS9dwv4A%2Bbj9c4y4o4%2BWG0y3NCBNsZb_nAbYJFfMQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>


-- 
-- 
==
Daryl Egarr,  Director
Kawhai Consultants Ltd
Cell   021 521 353
da...@kawhai.net
==

-- 
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/CALzH9que%3Dp0XoFwo0oXu6ogJ%2B7df9pNFShM0D0%3D3RWRbGkx8ZQ%40mail.gmail.com.

Re: The blacklist / master issue

[Daryl]

Alexander,

"""What is more important here, Django doesn't have a strong rules for
making decision about how framework is building and changing"""

*You couldn't be more wrong with this statement.*

One of Django's strengths is that decision making is *not* polluted by one
strong opinion, a whim by a marketing department, or trend-following.
You should read this
https://docs.djangoproject.com/en/3.0/misc/design-philosophies/
and this
https://docs.djangoproject.com/en/dev/internals/organization/
to educate yourself about how a strong organisation ensures that decision
making is high quality, transparent and meritocratic.

D.

On Mon, 22 Jun 2020 at 07:11, Alexander Lyabah  wrote:

> Robert, thank you for your response.
>
> For me, as an experience developer, blacklist is more descriptive, since I
> saw this word in so many other places, languages, frameworks. But it is
> just me, I'm here not to say that my opinion is more important than anyone
> else's.
>
> . Next week US-news will have a new subject for discussion, new words will
> be claimed to be abusive, new django community member will find an abusive
> word in source code (or sounds like it or very close to it), and community
> will be happy to claim this word to be not that descriptive, and find a
> better, more description replacement for it.
>
> with big respect
>
> On Sunday, June 21, 2020 at 6:54:57 PM UTC+3, Robert Roskam wrote:
>>
>> Hey All,
>>
>> I see this opportunity to rename these things to be what they in plain,
>> descriptive language. Since we will rarely have as many people together
>> considering this change, I find it useful to think what we would have named
>> these things from the beginning and then consider if our naming could be
>> more clear.
>>
>> I also found the term master odd when I first started using git. It
>> didn't map to anything or have an analogy that I found useful. If we
>> switched to main/trunk or whatever Github decides on, I don't much care
>> what the new name scheme is.
>>
>> Further, I find the allow/deny, accept/block for lists of things as far
>> more descriptive.
>>
>> Some elaboration: when I first came into professional technical circles,
>> I found the tendency to use color as a short-cut for culturally accepted
>> meaning to be potentially confusing to those from other cultures.
>> White/black, red/green/yellow may have received _technical_ meanings from
>> the last 50-60 years or so from the American-centric culture, and I speak
>> ignorantly, since I'm an American, but I don't know if I can assume that
>> other cultures do the same.
>>
>> Robert Roskam
>>
>>
>>
>> On Monday, June 15, 2020 at 12:28:23 PM UTC-4, Tom Carrick wrote:
>>>
>>> This ticket was closed wontfix
>>> <https://code.djangoproject.com/ticket/31670#ticket> as requiring a
>>> discussion here.
>>>
>>> David Smith mentioned this Tox issue
>>> <https://github.com/tox-dev/tox/issues/1491> stating it had been
>>> closed, but to me it seems like it hasn't been closed (maybe there's
>>> something I can't see) and apparently a PR would be accepted to add aliases
>>> at the least (this is more recent than the comment on the Django ticket).
>>>
>>> My impetus to bring this up mostly comes from reading this ZDNet article
>>> <https://www.zdnet.com/article/github-to-replace-master-with-alternative-term-to-avoid-slavery-references/>
>>> - it seems like Google have already made moves in this direction and GitHub
>>> is also planning to. Usually Django is somewhere near the front for these
>>> types of changes.
>>>
>>> I'm leaning towards renaming the master branch and wherever else we use
>>> that terminology, but I'm less sure about black/whitelist, though right now
>>> it seems more positive than negative. Most arguments against use some kind
>>> of etymological argument, but I don't think debates about historical terms
>>> are as interesting as how they affect people in the here and now.
>>>
>>> I don't think there is an easy answer here, and I open this can of worms
>>> somewhat reluctantly. I do think Luke is correct that we should be
>>> concerned with our credibility if we wrongly change this, but I'm also
>>> worried about our credibility if we don't.
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To u

Re: The blacklist / master issue

[Daryl]

The focus while reading the Django pages should be on the differences
between Django's governance approach (long term goal settings, a board of
technical experts, meritocratic decision making) vs the many frameworks and
projects that have flashed in the pan (please excuse me for using a phrase
that some languages might not understand).
Typically flash-in-the-pan projects have fewer experts, and control and
decision making is *usually* meritocratic but sometimes egocentric.
Eventually, no matter how bright the initial flash is, decisions by the
self-chosen few are made that result in the failure of the project.

This isn't to say that a failed project is not of value - many of the
learnings from failed projects are rolled into even better projects, but
this is not what Django is about. The developers quickly realised (way back
in the days when the initial developer's own newspaper project was the
largest Django installation around) that a strong governance structure
would be required.

With regard to the current "hot" topics (master/slave and blacklist /
deny), these may be viewed as trend-following, but a deeper study of both
nomenclature will inform you that current technology in databases no longer
follows the original meaning of master / slave, so a new or different name
is required. This might not suit people of my age who grew up with
master/slave databases and understand the non-racist use of the words, but
why should the current nomenclature suit just me?
Master / slave patterns still exist in some databases, but generally the
idea of one node being a master is getting rare. This is somewhat poetic,
as it mirrors the real world where in most countries, where the trend is
(hopefully) away from master / slave relationships.

My personal opinion for the 2nd topic (blacklist / whitelist / allow /
deny) is that this is a good time to pick a more descriptive name, and
allow/deny would mirror the linux hosts.allow and hosts.deny logic that has
been perfectly apt for 4 decades or more, and AFAIK is a better description
in most spoken languages in use today. You (Alexander) may prefer
"blacklist", and some of the technical board may also prefer "blacklist" (i
don't know) but you can rest assured that the decision would have been made
without significant weight being applied to the technical board member's
*personal* experiences, but the experiences of every *future* user of the
framework.

Finally,  in order to argue against changing these names (which has been
pointed out has already been merged) you would have to come up with an
argument to show reputational or technical harm would be done by changing.
Of all the users who have posted on the list who *disagree* with the
changes, none have written an argument with substantial merit in my opinion.

Remember, it's all about the future users of Django, not just the current
users.

D




On Mon, 22 Jun 2020 at 08:10, Alexander Lyabah  wrote:

>  Daryl, that is very strange, that you bring it here now.
>
> > One of Django's strengths is that decision making is *not* polluted by
> one strong opinion, a whim by a marketing department, or trend-following.
>
> renaming whitelist and blacklist is exactly what is in trend right now. I
> understand that not everybody are following US-news, but if you google
> "blacklist blm" you will find, how big the trend is, actually.
>
> Also, thank you sharing those link, but can you plz elaborate more, why do
> you bring those and what do you what to proof by sharing those links, so
> when I read those links again, I know on what point I should focus more.
>
> Thank you for being involved in this conversation.
>
> --
> 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/267f6649-a434-47fb-93c9-880b594d213ao%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/267f6649-a434-47fb-93c9-880b594d213ao%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
-- 
==
Daryl Egarr,  Director
Kawhai Consultants Ltd
Cell   021 521 353
da...@kawhai.net
==

-- 
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/CALzH9qvXHbXVdOVDRJaTm6%2Bh_egPbxk%3DHLQmL%2B%2B%3DSFDxf53T3A%40mail.gmail.com.

Re: The blacklist / master issue

[Daryl]

>
> In this word developers said "We 100% support BLM, we against any racism.
> Some of community members have sent proposal for renaming blacklist, but we
> 100% sure, that this term has nothing to do with racism. Moreover, terms
> can't explain things 100% clear, we just use those terms to explain things
> faster. Because we are here is not for inventing and reinventing new terms,
> we are here for building new things. Let me explain in example. When one
> dev from US said to another dev from France - "don't forget to add
> blacklist functionality here", that explains a lot, because term blacklist
> is commonly known term. Someone, from community have an idea to rename all
> blacklist in source code to allowlist, and don't use term "blacklist" at
> all. Well in that case when dev from France will ask "allowlist is a list
> which is allowed to be expended? Or allowlist is a list that is allowed to
> be used by other lists?", the US-dev will answer "No, don't use read
> US-newspapers? allowlist is the same as blacklist but without racism",
> thats why we don't want to reinvent terms for what ever reason. Thank you
> for understanding"
>

"blacklist" isn't as widely understood as you presume, and if you survey
people (but I can't provide the source i have seen in the past) you will
find that more people understand what it means to "deny" than to
"blacklist". QED.

But in the same world astrophysicists haven't been that wise, so they
> claimed: "We 100% support BLM, we against any racism. Thats why we decide
> not to use term "black hole" instead we will use term "heavy thing", we've
> asked a lot of other astrophysicists and they all agree that "heavy thing"
> explains thing better, of course, we are not following for renaming trend,
> we are here for science, it is just a good time to rename something that we
> have planed to rename long time ago. Remember, this all is for future
> generation of astrophysicists not for current generation, because we think,
> that the next generation will be much dumber and we should help them to
> understand new terms"
>
>>
>> That's a facetious argument - black holes are named for their color.

-- 
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/CALzH9quLEbWPn9FHYfs6NQtTKpZBDSeRCmwj8H84-bSvqWmkTg%40mail.gmail.com.

Re: Instance Based Management?

[Daryl]

What you are describing sounds like denormalisation, but the first step
would be to ensure that the indexes on the child tables are being created.

The query time to find rows if the lookup field is indexed is close to
linear, without an index it will be close to exponential.
You should only denormalise after you have investigated the root cause of
your performance issues. Most times, denormalization is a form of premature
optimization [ https://stackify.com/premature-optimization-evil/ ]
If you are talking about virtual denormalisation (ie a view or table
generated by the manager you mention) then this relies again on indexing of
the underlying data to work, so you get no performance gain.
Correct me if I'm wrong, but AFAIK this is true of most managers - they
help you with your logical view of the data, not the performance of
retrieving it.

There are many django deployments where the performance is fine with orders
of magnitude more data than you are referring to, it just takes careful
planning.

D


On Tue, 27 Oct 2020 at 13:40, Matthew Amstutz 
wrote:

>
> Hello, I was wondering about instance based management. If I'm wrong,
> please tell me.
>
> When we have users and user generated content in a large database, query
> times are increased significantly. Why is there no instance based manager
> (like the models.Manager()) that basically generates a table for each user
> and queries ONLY that table? Would that not just flatten the database
> instead of increasing it's size? For example, if we have 1,000,000 users
> all of which generate at least 10 posts per day and one of the users only
> generates 5 in the span of 10 days, unless we have a many to many field or
> something to hold those five posts, the query time to find their posts
> would be ridiculous.
>
> So if we have a table generated for each user that holds arbitrary
> connections to anything they generate, it would in theory cut query times
> significantly. Why is there no feature like this? Again, if I'm wrong
> please tell me but the amount of tables doesn't matter and instead the data
> they hold does so, in my understanding, 1,000,000,000 posts will always be
> the size of 1,000,000,000 posts no matter their organization.
>
> I've got ideas on implementation and even asyncronous supports as well as
> customization but I have no idea how to bring this up to the django
> developers and I'm not even sure it would work (though, no matter how hard
> I try, I can't see anything wrong with it).
>
> Let me know your input and if there's a way I can ask the django devs
> about this and possibly even suggest a few things pertaining to it. I'd
> like to help make django the best it can be and if this works and we can
> implement it, django will be very fast with user generated content.
>
> --
> 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/7e36ded7-2f3d-43c2-881c-cbc75c80b5c2n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/7e36ded7-2f3d-43c2-881c-cbc75c80b5c2n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
-- 
==
Daryl Egarr,  Director
Kawhai Consultants Ltd
Cell   021 521 353
da...@kawhai.net
==

-- 
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/CALzH9quw5tSNNuAe%2Bspt9edTcJWV_ckUqdiyEtW5Qybx9kFepQ%40mail.gmail.com.

Re: Adding a security concerned feature

[Daryl]

My 2c:

The analogy is pretty straightforward here;
- changing the admin URL is like putting your house's front door key slot
in a strange, unique place, so that additional *knowledge* is required to
unlock it.
- django-axes, fail2ban, etc is like having a bouncer standing beside the
door, watching for suspicious activity and ejecting anyone who
clearly doesn't have a genuine key.

Changing your admin URL is not a waste of time, but if your time is
precious, spend it on ensuring your users have strong passwords, and that
your logon page can't be abused.

D



On Thu, 3 Dec 2020 at 07:08, 'Aaron C. de Bruyn' via Django developers
(Contributions to Django itself)  wrote:

> On Wed, Dec 2, 2020 at 9:23 AM Collin Anderson 
> wrote:
>
>> > combination of blocking IPs and having a different admin URL would
>> raise the bar quite a bit.
>>
>> So having a different default admin URL would help, right?
>>
>
> Sure.  But so would disconnecting the network cable from your server. :)
> It's all about practicality.
>
> Using something similar to django-axes raises the bar quite a bit, but
> simply obscuring the URL doesn't do much.
>
> I have plenty of apps exposed with the admin URL being '/admin/', but no
> one's been able to compromise the site because I use django-axes to block
> repeated attempts, and I have a strong password.  On several of the sites I
> require logins with a YubiKey.
>
> In my worthless opinion, I think it would be better to leave it in the
> urlconf but commented out with a note that says "you might want to change
> the admin URL to something different before you enable it for $REASONS".
> Maybe have something in the docs on deploying your code into production
> that goes over it too.
>
> -A
>
> --
> 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/CAEE%2BrGqvVXrAZbWwuieitTVTNuKzR%2B%2BWWqc-6HsO4LO0OhvEog%40mail.gmail.com
> <https://groups.google.com/d/msgid/django-developers/CAEE%2BrGqvVXrAZbWwuieitTVTNuKzR%2B%2BWWqc-6HsO4LO0OhvEog%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
>


-- 
-- 
==
Daryl Egarr,  Director
Kawhai Consultants Ltd
Cell   021 521 353
da...@kawhai.net
==

-- 
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/CALzH9qupvNQuaRF4jyTXM684DdNi%3DVWeN6W7pFJhZaVQJY9zyw%40mail.gmail.com.

Re: GSOC Proposal : A new AUTH library.

[Daryl]

I'd add this to the direction Shai's comment is going (if i've interpreted
Shai's commments correctly);

Some Django components (such as how static files are served) often change
during the production life of a project; the way you auth users almost
never changes, or if it does, it changes once.
This leads to the conclusion that an auth library that provides more than
one type of auth is counter productive - if your auth library provides auth
mechanisms A, B, C and D, and D has a bug that needs fixing, all users who
only use A B or C need to also upgrade your library (or at least need to
review the changes to determine they actually *dont* need to upgrade).
The gains from being able to switch from D to [A B or C] and still use the
same library are almost non-existent. Even if switching doesn't require
"pip install [alternative auth library], it *will* require a code review
because of how different each auth mechanism is.
So even if you were to come up with a significantly better A, B, C or D
library than the current options, your chances of getting it accepted into
regular community use are much better if they are separate libraries.
This doesn't mean its not a worthwhile project or GSOC proposal, its just a
fact of software design and planning.

D




On Fri, 16 Apr 2021 at 06:32, Shai Berger  wrote:

> Hi Nikhil,
>
> I am not calling the shots here, just a member of the community.
> However, if you are suggesting this as a work on a 3rd-party library, I
> think your suggestion should be either for something completely new, or
> a significant improvement over existing 3rd-party libraries. Libraries
> which support registration, OAuth, and 2FA, all exist -- in fact, more
> than one for each of the above. I suggest that you research them a
> little, and reformulate your suggestion to show how you'd make a
> significant contribution beyond what they already offer.
>
> Cheers,
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/20210415213200.72371c9f.shai%40platonix.com
> .
>


-- 
-- 
==
Daryl Egarr,  Director
Kawhai Consultants Ltd
Cell   021 521 353
da...@kawhai.net
==

-- 
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/CALzH9qvXE%2BoK3%2BM8uxNiJ4Sij4_yHT_aWvQhReAmZNSZjBd_GA%40mail.gmail.com.

Re: Deprecation of using pk in public ORM API

[Daryl]

Hi Albert,

I think you are going in the wrong direction here; We should leave the 'pk'
alias in place, not because it would be hard to remove, and not because it
exists in many places, but because aliasing is a stonking great idea.

It exists in many places for precisely that reason ; its such a great idea
that almost every subsystem uses, or at least offers, aliasing in some way.

To successfully argue that having a 'pk' alias is a negative feature of the
code base, you would have to also convince all the MySQL, MSSQL, Oracle and
PostgreSQL devs , plus all the other framework devs, that aliasing is a bad
thing, and that would be a herculean task.

However, you have already reaped the rewards of your investigation; which
is a greater understanding of the code base, and how the awesomeness of
aliasing is used in Django, and you can now apply the pattern to many other
situations.

D



On Wed, 2 Feb 2022 at 00:31, Albert  wrote:

> Thank you for response.
>
> Now i see that it is not so easy as I thought.
> It is used in many other places in Django and probably also in django rest
> framework and other third parties libraries.
>
>
> --
> 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/hpkfxawtvfvrsbioliha%40erjj
> 
> .
>


==

-- 
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/CALzH9quuH7K1gYGbx0JZCgJ7L1i4myKBRDZirheK9VctFWpssQ%40mail.gmail.com.

Re: Revisiting MSSQL and Azure SQL Support in Django

[Daryl]

My 2c;

The technical board has always done a stellar job of ensuring that good
ideas end up in the code base, and unfinished, unsupported, incomplete,
young, or non-reviewed code stays outside.
The quality of the core framework, and the ease of having 3rd party code
exist as Extensions, Plug-ins and Related Libraries means that the
technical board can be -1 on a request to add code to the core framework
without negatively impacting that code's future potential. It might be a
blow to the author(s) ego, but saying "No" isn't going to make the code any
harder for end users to find, install, review, debug, and it gives the code
more time to be improved. In the future, if the code demonstrates
stability, performance and user support, maybe it gets another chance to be
merged into core.
Django's quality is, in part, a direct result of saying "No" at the right
times.

No personal disrespect intended the the authors of the MSSQL backend
package (haven't seen it, haven't used it, probably never will given the
quality of other available backends) but after spending nearly 3 decades
developing with OSS DBs and MSSQL, at times teaching design and DBA, and
having to support MS server and DB systems, Microsoft's code teams (in my
opinion) haven't shown a commitment to high quality, peer reviewed code.
Microsoft's marketing, telemetry and legal teams however have shown a very
strong commitment to put their own interests above those of the users.
This may well be a reflection of (again, my opinion) the 'profit first,
image second, quality where possible (security if we get time or negative
PR requires it)' theme that permeates MS.

Code must stand on its own merits, and no code decision should be
influenced by the reputation of the author, either negatively or
positively, but having said that, if the technical board were to decide to
include the MSSQL backend in core, there would have to be a commitment to
review every single commit from that point on, specifically looking for the
ways MS will put pressure on the codebase to bend towards the MS goals, not
the Django goals. Where the goals are the same, that is fine. I remain
skeptical that the goals are the same.

Finally, I congratulate Warren for getting the code this far.

D





On Fri, 1 Apr 2022 at 05:30, Warren Chu  wrote:

> Hi All,
>
> There is increasing interest within Microsoft to have stronger ties
> between Microsoft SQL Server and Django. As you may be aware, Microsoft and
> their connectivity teams have been managing the 3rd party backend for
> "mssql-django" for over a year now at:
> https://github.com/microsoft/mssql-django
>
> Inclusion of SQL Server as a 1st party backend is viewed as a potential
> big milestone in that regard.
>
> @adamjohnson mentioned a year ago that ideally the community would like to
> see multiple years of ongoing Microsoft support before considering merging
> as a 1st party backend.
>
> We'd love to hear thoughts and feedback around the possibility of moving
> forward with a DEP enhancement proposal, with a commitment from Microsoft
> to providing continued dedicated support for the 1st party backend through
> the Django project itself (rather than the 3rd party repo).
>
> Cheers,
> Team Microsoft
>
> --
> 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/0c6ca059-d50e-4c84-bef6-ab0742fc4fa9n%40googlegroups.com
> <https://groups.google.com/d/msgid/django-developers/0c6ca059-d50e-4c84-bef6-ab0742fc4fa9n%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>


-- 
-- 
==
Daryl Egarr,  Director
Kawhai Consultants Ltd
Cell   021 521 353
da...@kawhai.net
==

-- 
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/CALzH9qvTRkK_Q%3DFMkhAhxQaUXgd%3D%3DCjW467%2BisZJyxKrHeR5Bw%40mail.gmail.com.

Re: Binding LiveServerTestCase bind to port 0

[Daryl]

Wow : +8 −100 for that commit - that's a great re-factoring :)

On 17 June 2016 at 13:23, Tim Graham  wrote:

> In IRC the other day, Donald pointed out
> https://www.dnorth.net/2012/03/17/the-port-0-trick/ and suggested that
> Django might be able to take advantage of that technique.
>
> I put together a proof of concept that seems to work:
> https://github.com/django/django/pull/6791
>
> I'm wondering if anyone sees any problems with this approach and if
> there's any use case for continuing to support customizing the address
> using the DJANGO_LIVE_TEST_SERVER_ADDRESS environment variable.
>
> --
> 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/148d1019-0e5b-4078-88f0-74adc92db08e%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/CALzH9qtN2rnFVbsm9Vrox%2BMv2qi-TJrJftTrRp4gBcUYs3FLHg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Multiple database support

[Daryl Spitzer]

Another couple weeks have slipped by and I continue to be crazy-busy.
(But each week I'm busy for a different reason--so I continue to be
foolishly optimistic that I'll soon get a week with some free time.)

Anyway, I don't have time to read this thread through with the care it
deserves, but I thought I shouldn't let that stop me from finally
writing a description of the API I proposed at the PyCon sprint.

Each app would have a databases.py file that contains classes used to
define databases connections (in the same manner as classes are used
to define models).  Here's an example:



from django.db import connections

class LegacyDatabase(connections.DatabaseConnection):
   engine = 'sqlite3'
   name = '/foo/bar/legacy_db.sqlite3'



(And the other DATABASE_* settings (from settings.py) could certainly
be defined as attributes of a DatabaseConnection class.)

JUST FOR TESTING, I propose we allow a database connection to be
specified in a model with a Meta attribute, like this:



from django.db import models
from legacy.databases import LegacyDatabase

class LegacyStuff(models.Model):
...

class Meta:
db_connection = LegacyDatabase



Jacob expressed his extreme distaste for this at PyCon--for good
reason.  (We don't want to encourage coupling models to databases.)
But just so we can get a working patch and start testing, I propose we
go with this for now.

Adrian suggested we allow the specification of database connections
per-app using the new app() function being proposed for settings.py.
I haven't seen a description of this since PyCon, but I think it would
look something like:

app(name='legacy', db_connection='LegacyDatabase')

(I'm sure I'm leaving several important arguments out of this example.)

Perhaps one could implement sharding by defining multiple
DatabaseConnection classes in a databases.py file (we could support
these files at the project level in addition to the app level) and
putting them in a list.  Then one could write a function to return the
appropriate database to use and specify that callable in the argument
to the app function (or perhaps as an argument to the url function in
urls.py).

I haven't given any thought to replication.  Perhaps someone who needs
this could think about whether this proposal could somehow make
supporting replication easier (or if it might get in the way), or if
it's simply orthogonal to this.

--
Daryl


On Wed, May 28, 2008 at 12:25 AM, koenb <[EMAIL PROTECTED]> wrote:
>
> On 22 mei, 18:28, "Ben Ford" <[EMAIL PROTECTED]> wrote:
>> Hi all,
>>
>> I've now re-applied Daryls patch (which was against qsrf) to a clone of
>> django trunk in a mercurial repo. It's available 
>> athttp://hg.woe-beti.deandthere's a trac set up for it 
>> athttp://trac.woe-beti.de. Feel free to make use of both of these. Although
>> I've disabled to ability to create tickets perhaps the wiki might be a good
>> place to discuss the API? Anyone can clone from the hg repo, give me a shout
>> if you would like push access and I'll sort it out.
>>
>> Cheers,
>> Ben
>>
>> --
>> Regards,
>> Ben Ford
>> [EMAIL PROTECTED]
>> +447792598685
>
> I have been adding some code to Ben's mercurial repo on [http://hg.woe-
> beti.de], see also [http://trac.woe-beti.de].
>
> What has been realised (more or less):
> - connection and model registration
> - validation that related objects use the same connection
> - database_engine specific SQL generation (needs more checking)
> - some management commands accept connection parameter, others can
> generate output for multiple connections
> - syncdb can sync different connections
> - transaction management over connections
> - some tests (needs a lot more work)
>
> This means point 3 of the discussion at [http://trac.woe-beti.de/wiki/
> Discuss] is somewhat working, but definitely needs a lot more testing.
>
> I do need some help with creating tests for all this though.
> I have not figured out yet how to create tests that check that the
> right SQL is being generated for the backend used. (Nor how to test
> the right database was touched by an action, this is quite obvious
> manually, but I do not know how to automate this.)
>
> I put some ideas on using multiple databases for copying (backup or
> migration) of objects (point 4 of the discussion note) in [http://
> trac.woe-beti.de/wiki/APIModelDuplication].
>
> Please comment, add, shoot etc. Any help will be much appreciated.
>
> Koen
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Re: Porting Django to Python 3.0 as a GSoC project

[Daryl Spitzer]

Jacob writes:

> It's hard enough maintaining 2.3, 2.4, and 2.5 side-by-side...

Do you maintain them side-by-side, or do you just reject patches that
require new features introduced in 2.4 and 2.5?  (I just assumed that
you maintain 2.3 compatibility by testing on 2.3.)

--
Daryl


On Thu, Mar 27, 2008 at 12:43 PM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
>
>  On Thu, Mar 27, 2008 at 2:30 PM, Rodrigo Bernardo Pimentel
>  <[EMAIL PROTECTED]> wrote:
>  >  Thanks again for your feedback, James! I'd love to hear more from other
>  >  developers on this matter.
>
>  I have to say I agree with James on this one. SoC projects out to be
>  stuff that can *finished* in a couple of months; Django on 3.0 is a
>  long process, and a sorta-kinda version just isn't worth anyone's
>  efforts.
>
>
>  >  I have a different view of GSoC projects. I don't think it should be an
>  >  isolated, "end of summer, end of story" project.
>
>  I'm really glad you see it that way -- my dream for SoC is that
>  students stick around and become contributors. However, that's
>  something that's impossible to predict so we have to be pragmatic in
>  what projects we accept. I have no reason to doubt your commitment,
>  but something as big and open-ended as this project just isn't a good
>  match.
>
>  The biggest problem is maintainance. I don't think we've got the
>  collective time and energy to maintain two parallel versions of Django
>  -- even if one version is automatically generated with 2to3. It's hard
>  enough maintaining 2.3, 2.4, and 2.5 side-by-side; 3.0 isn't yet worth
>  the effort.
>
>  We've committed to 2.3 compatibility in Django 1.0, and that's what
>  we'll do. Once that's behind us, we can start dropping older versions
>  until we're ready to make the big jump.
>
>  Jacob
>
>
>
>  >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Re: Porting Django to Python 3.0 as a GSoC project

[Daryl Spitzer]

On Fri, Mar 28, 2008 at 8:57 AM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:

>  On Thu, Mar 27, 2008 at 5:10 PM, Martin v. Löwis
>  <[EMAIL PROTECTED]> wrote:
>  >  So leave the code as-is, and have 2to3 fix it at installation
>  >  time (whenever setup.py is invoked by 3.x; setup.py itself
>  >  runs without changes on 3.x)
>
>  Ahh -- this was the part I was missing; my apologies for being dense.
>  I've been thinking of 2to3 as a one-time tool -- run it to move to
>  3.0, and never look back -- not as part of a distribution process.

Unless I'm missing something, wouldn't Django likely have to include
code that would only work on 2.6 for this to work?

--
Daryl


On Fri, Mar 28, 2008 at 8:57 AM, Jacob Kaplan-Moss
<[EMAIL PROTECTED]> wrote:
>
>  On Thu, Mar 27, 2008 at 5:10 PM, Martin v. Löwis
>  <[EMAIL PROTECTED]> wrote:
>  >  So leave the code as-is, and have 2to3 fix it at installation
>  >  time (whenever setup.py is invoked by 3.x; setup.py itself
>  >  runs without changes on 3.x)
>
>  Ahh -- this was the part I was missing; my apologies for being dense.
>  I've been thinking of 2to3 as a one-time tool -- run it to move to
>  3.0, and never look back -- not as part of a distribution process.
>  Neat trick -- wish I'd thought of it :)
>
>  So this means, though, that folks running from SVN will still need to
>  run setup.py every time they update, right? Not that that's a
>  dealbreaker -- I think Django-on-Py3k'ers will be on the cutting edge
>  anyway -- just wanna check.
>
>  I'd still be happier thinking about this process post-Django-1.0 and
>  post-Py3k-release (or at least rc status), but I've got no objections
>  to other folks working on it until then.
>
>  As for SoC, I can only see it working under these conditions:
>
>  (1) A student with a fair deal of both Django and Python knowledge.
>  The Python knowledge is more important; the places where bugs in
>  Django are going to crop up are going to be internal, undocumented
>  areas. This student also should probably be prepared to work with 2to3
>  fixers, though I've got a lot of knowledge here and can help out.
>  (2) A mentor ditto. I suspect finding a mentor interested in this
>  project could be difficult.
>  (3) Willingness from both parties to work from Martin's plan/patches
>  forward. Now that I understand how he's going about this, I'm
>  convinced it's the correct path.
>  (4) A *realistic*, *solid* project plan -- with dates -- that clearly
>  lay out what "success" means in this context. This plan should *not*
>  define "success" as "all code merged into Django in August" since that
>  probably will depend on lots of factors out of your control.
>  (5) A commitment from mentor and student to stick around after the SoC
>  and help idiots like me get the code merged once the time comes.
>
>  Jacob
>
>
>
>  >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Re: Porting Django to Python 3.0 as a GSoC project

[Daryl Spitzer]

I think you misunderstand the role of 2.6.  See the seven steps under
"The recommended development model for a project that needs to support
Python 2.6 and 3.0 simultaneously..." in
http://www.python.org/dev/peps/pep-3000/#compatibility-and-transition.
 Step 1 reads "Port your project to Python 2.6."

And step 6 is "If problems are found, make corrections to the 2.6
version of the source code and go back to step 3."  I take this to
mean that one likely needs to make 2.6-specific changes in order to
get the code working on 3.0 after running it through 2to3.

--
Daryl


On Fri, Mar 28, 2008 at 12:32 PM, Patryk Zawadzki <[EMAIL PROTECTED]> wrote:
>
>  On Fri, Mar 28, 2008 at 8:07 PM, Daryl Spitzer <[EMAIL PROTECTED]> wrote:
>  >  On Fri, Mar 28, 2008 at 8:57 AM, Jacob Kaplan-Moss
>
> >  >  Ahh -- this was the part I was missing; my apologies for being dense.
>  >  >  I've been thinking of 2to3 as a one-time tool -- run it to move to
>  >  >  3.0, and never look back -- not as part of a distribution process.
>  >  Unless I'm missing something, wouldn't Django likely have to include
>  >  code that would only work on 2.6 for this to work?
>
>  As far as 2to3 is involved, you are supposed to modify the python 2.5
>  code until 2to3 gives perfect conversion, not play with the results.
>  The goal is to prepare the code so the future move involves running
>  one tool, not to convert now and drop 2.5 support. So the only way
>  this could work is to alter possibly ambiguous 2.5 code and watch the
>  diffs generated by 2to3 without actually switching to python 2.6/3.0.
>
>  --
>  Patryk Zawadzki
>  PLD Linux Distribution
>
>
>
>  >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Re: Porting Django to Python 3.0 as a GSoC project

[Daryl Spitzer]

Ah.  I'm glad I brought it up.

When the time comes to port my code, I'll try skipping step 1 first.

--
Daryl


On Fri, Mar 28, 2008 at 5:48 PM, Martin v. Löwis
<[EMAIL PROTECTED]> wrote:
>
>  >  I think you misunderstand the role of 2.6.  See the seven steps under
>  >  "The recommended development model for a project that needs to support
>  >  Python 2.6 and 3.0 simultaneously..." in
>  >  http://www.python.org/dev/peps/pep-3000/#compatibility-and-transition.
>  >   Step 1 reads "Port your project to Python 2.6."
>
>  I believe this recommendation is flawed. It assumes that it is acceptable
>  that you break 2.5-and-earlier compatibility in the process of porting to 
> 2.6.
>  This, in turn, is assumed because it was considered impractical to have
>  code that runs on 2.3, yet 2to3 could still fix it correctly. Again in turn,
>  this assumption results from the actual lack of opportunity to try out any
>  other strategy.
>
>  At the PyCon sprint, I tried a different strategy for Django, and it seems
>  to work fairly well.
>
>  The authors of the PEP certainly did not mean to say that 2to3 can't possibly
>  create correct output if applied to source that also runs on 2.5.
>
>  Regards,
>  Martin
>
>
>
>  >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Multiple database support

[Daryl Spitzer]

I've unfortunately been too busy to make time to work on this since
PyCon.  The last thing I've done (after writing some code on the
flight home) is to send a patch to Ben Ford.  Not long after that Ben
created a Mercurial repository (with my patch) and a Trac project.
You'll want to contact him.

I would still like to get my patch working so others (and myself) can
start testing it.  I won't have time this week, but so far it looks
like I may be able to make some time next week.  If I don't, I see if
I can at least make enough time to write up the API I came up with at
PyCon.

--
Daryl


On Tue, May 20, 2008 at 8:05 AM, Casper Jensen <[EMAIL PROTECTED]> wrote:
>
> On Tue, May 20, 2008 at 4:56 PM, Nicola Larosa (tekNico)
> <[EMAIL PROTECTED]> wrote:
>> It would be nice to coordinate each one's efforts, to avoid wasting
>> time. Ben, Daryl, any news?
> Currently, I have not worked on the project, since the proposal,
> because of job and university commitments. I plan to track the
> development at begin to help with the development when I get more time
> (over the summer).
>
> - Casper
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: document based database

[Daryl Spitzer]

Perhaps bedros meant to ask if anyone is working on support in Django
for any "document based" databases.

strokeDB looks (to my untrained eye) similar to CouchDB.  You'll find
plenty to read if you do a search for "couchdb django".

--
Daryl


On Tue, May 20, 2008 at 4:06 PM, Collin Grady <[EMAIL PROTECTED]> wrote:
>
> bedros said the following:
>> are you guys aware of any document based database open source
>> implementation in Python such as strokeDB for Ruby
>
> This question does not belong on this list - this list is for the discussion 
> of
> the development of django itself, not for other questions.
>
> --
> Collin Grady
>
> The nation that controls magnetism controls the universe.
>-- Chester Gould/Dick Tracy
>
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---

Re: Multiple database support

[Daryl Spitzer]

> Is there a ticket in django we could use to track progress on this? We could
> use 4747, but if we do decide on a new API that might be a bit confusing...
> We could of course just use the mailing list and trac project, thoughts?

There's also http://code.djangoproject.com/ticket/1142.  With the
mailing list and trac project, do we need a ticket for more than just
a place to attach patches to invite others to test?

> I'll sort out the hg repo (it now needs to point at trunk - not qsrf) and
> trac project if I get time this evening and make it public readable for
> everyone who's interested.

Thanks Ben.

--
Daryl


On Wed, May 21, 2008 at 3:33 AM, Ben Ford <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I'll sort out the hg repo (it now needs to point at trunk - not qsrf) and
> trac project if I get time this evening and make it public readable for
> everyone who's interested.
>
> Is there a ticket in django we could use to track progress on this? We could
> use 4747, but if we do decide on a new API that might be a bit confusing...
> We could of course just use the mailing list and trac project, thoughts?
>
> It's great to see some interest in multiple db support again :-)
>
> Ben
>
> 2008/5/20 Nicola Larosa (tekNico) <[EMAIL PROTECTED]>:
>>
>> Daryl Spitzer wrote:
>> > If I don't, I see if I can at least make enough time to write up the API
>> > I came up with at PyCon.
>>
>> Please do, that would be great.
>>
>> --
>> Nicola Larosa - http://www.teknico.net/
>>
>>
>
>
>
> --
> Regards,
> Ben Ford
> [EMAIL PROTECTED]
> +447792598685
> >
>

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---