Having run in to this issue in the past, automatically changing the meaning
and/or breaking the query can turn in to a debug time sink. Option 3 could
save people a bit of time.
Cheers,
Michael Manfre
On Wednesday, October 28, 2020 at 8:46:46 PM UTC-4 charettes wrote:
> I'm also
tabase backend
API, I suggest clearly stating that it will still be exempt from the
standard deprecation policy. There was a lot of strong opposition to
changing that policy in the past.
Regards,
Michael Manfre
--
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre
--
You received this me
This mailing list is for the development of the Django Framework. Questions
related to its usage should be posted to the django-users mailing list.
Regards,
Michael Manfre
On Fri, Nov 9, 2018 at 6:51 AM wrote:
> Hi all,
>
> I have a very simple Profile class:
>
> class Profi
This mailing list is for the development of Django itself, not how to use
Django. The mailing list django-users is where you can ask this type of
question, but you will need to make your question a bit more detailed, if
you'd like to get a helpful response.
Regards,
Michael Manfre
On Wed, O
nk we
should improve that. I'm +1 on reopening the ticket to make it easier to
swap in a custom ExceptionReporter for AdminEmailHandler.
Regards,
Michael Manfre
On Mon, Aug 27, 2018 at 9:41 AM wrote:
> Email error reports sent from Django (when DEBUG=False) include
> information abo
that
they would likely ignore.
Regards,
Michael Manfre
On Sat, Aug 25, 2018 at 9:12 AM Tim Graham wrote:
> Alex proposed:
>
> ---
>
> Pickle serializer has long been known to be dangerous. This is mitigated
> by requiring MAC on pickle in cookies, but nevertheless, RCEs con
On Mon, Jul 23, 2018 at 12:12 PM Florian Apolloner
wrote:
> * Any thoughts on asset pipelines?
>
This seems like it would be critical functionality. It might also help
users to avoid potential asset ordering issues without needing to create
more apps to resolve conflicts.
Regards,
M
Any improvements to documentation are greatly appreciated. Thank you for
taking the initiative.
Regards,
Michael Manfre
On Mon, Feb 5, 2018, 7:05 AM David Foster wrote:
> This weekend I spent several hours getting Channels configured to run a
> simple chat server <https://github.com/
me structure, how much of a safe assumption is this?
>
Every 3rd party database backend adheres to the internal API and must
provide its own or an inherited DatabaseWrapper. Adding config_from_url
seems like the best place to me.
Regards,
Michael Manfre
--
You received this message because you ar
as definitely a
lot of fun to tinker on it, but not something I'd ever want to support in
production.
Regards,
Michael Manfre
On Fri, Sep 8, 2017 at 12:57 PM Adam Johnson wrote:
> I agree, I think forcing Django's ORM to work on MongoDB is not a great
> idea. Django relies he
On Tue, Sep 5, 2017 at 5:10 AM Adam Johnson wrote:
> from django.db.models import FilteredRelation is what I'd expect
>
This is what I'd expect too.
> On 5 September 2017 at 09:44, Nicolas Delaby wrote:
>
>> It seems we have a consensus.
>> I'll be glad to push that change.
>>
>> I just have
't support
that feature.
Regards,
Michael Manfre
On Mon, May 15, 2017 at 11:54 AM Tim Graham wrote:
> Does anyone know of a use case for using null bytes in CharField/TextField?
>
> psycopg2 2.7+ raises ValueError("A string literal cannot contain NUL
> (0x00) characters.&quo
there
being an officially supported MSSQL backend for Django. Microsoft has
continued to be involved with Django and myself related to making a better
MSSQL experience for us.
Regards,
Michael Manfre
On Fri, Apr 28, 2017 at 3:55 PM wrote:
> I wonder if there have been any updates on MS suppo
atabase backend, check out the
Custom Database Backends talk given at DUTH last year.
Regards,
Michael Manfre
On Sun, Feb 19, 2017 at 8:11 PM wrote:
How do I tell django to use --skip-secure-auth when connecting to mysql?
049, "Connection using old (pre-4.1.1) authentication protocol
SL sounds somewhat nice, I am -0 to -1 for the debugger --
> I've seen to many sites out there running with DEBUG=True, enabling RCE
> ootb seems to be pretty horrible.
>
I think anyone running devserver in prod deserves a breakpoint induced
outage.
Regards,
Michael Manfre
--
You
it as easy as possible for them to do so (e.g.
pre-notification), but not by adding more support burden (conditional code,
build matricies, etc.) to Django or preventing us from using newer features
from Python.
Regards,
Michael Manfre
--
You received this message because you are subscribed to the G
As some one who maintains django packages, I wouldn't use "django_" and
don't think it should be an official recommendation. I do support
documenting the potential collisions to let package maintainers make a more
informed decision.
On Thu, Dec 8, 2016 at 7:17 AM Adam Johnson wrote:
> +1 (to wha
go.
https://docs.djangoproject.com/en/dev/internals/mailing-lists/#django-users
Regards,
Michael Manfre
On Wed, Nov 30, 2016 at 8:14 AM Reetika Aggarwal <
reetika.aggarwa...@gmail.com> wrote:
> Hi,
> Getting below exception while makingMigrations
>
> django.core.exceptions.ImproperlyConfigur
nd
> certainly nothing specific to OrderBy. Your proposed syntax is basically
> what would be required `order_by=[ .. ]`.
>
>
We (or anyone) could make an ExpressionList class that is essentially an
Expression that is a list of expressions. It would basically be a
Combinable with com
, I don't think this is something Django
should officially support for the same reasons mentioned by Marc.
Regards,
Michael Manfre
On Mon, Oct 3, 2016 at 9:44 AM James Pic wrote:
> True, this is a feature that's been invented a countless number of times.
> Perhaps one impleme
Hi Robert,
Thanks for doing this load testing. More context would be useful to help us
outside observers to understand the potentially different variables. Is
redis running locally or are you using elasticache?
Regards,
Michael Manfre
On Mon, Sep 12, 2016 at 9:41 PM Robert Roskam
wrote:
>
custom User model; bonus points if they make it a reusable app or even a
gist.
Regards,
Michael Manfre
On Mon, Aug 1, 2016 at 9:03 AM James Pic wrote:
> Aymeric, it doesn't matter if tens of milions of names fit into your
> model, it only takes one to have a issue that's goin
;
I have no strong feelings either for or against it being in the official
Django documentation. I've been wanting to put together a talk about
creating a database backend and that will likely be the first pass at the
documentation.
Regards,
Michael Manfre
--
You received this message becaus
ase backend, please share them.
Regards,
Michael Manfre
--
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-develope
I can't recall the last Django project I worked on that didn't require
pytz. It makes sense to me to require it.
Regards,
Michael Manfre
On Tue, May 17, 2016 at 6:07 AM Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> The reasoning was based on:
>
>
ling with HIPAA (and some other compliance regulations) a few
months ago.
Regards,
Michael Manfre
--
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 receivin
Simple is better. Anyone who needs/wants something more complex is not
prevented by Django from doing so.
Regards,
Michael Manfre
On Mon, Mar 14, 2016 at 2:31 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Indeed, for some reason, the URL and email validators get
more
bandwidth starting the end of this month when things are finally settled.
Regards,
Michael Manfre
On Fri, Mar 11, 2016 at 1:54 PM, Tim Graham wrote:
> Yes, I wonder if Microsoft abandoned the idea of providing engineering
> resources to help out projects like django-mssql or if thin
of my primary
concerns because there are existing production sites that run Django on
Windows.
Regards,
Michael Manfre
On Wed, Jan 27, 2016 at 12:15 AM, Cristiano Coelho wrote:
> I'm interested in the progress of this as well :)
>
> Sorry I didn't read through all the posts, mostly
to me. Allowing both to be configurable requires a trivial
amount of extra effort to implement and maintain.
Regards,
Michael Manfre
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from t
Agreed with the above for the same reasons.
On Wed, Jan 6, 2016 at 9:17 AM, Shai Berger wrote:
> What Marc and James said, and in particular what Daniele said : I get to
> use Jira on a daily basis and find it cumbersome and confusing.
>
> Shai see
>
>
> On 6 בינואר 2016 15:43:02 GMT+02:00, Marc
It should be configurable and I like the kwargs idea. I've also had to
monkey patch JSONField in this way for datetimes.
Regards,
Michael Manfre
On Tue, Jan 5, 2016 at 12:48 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> > On 5 janv. 2016, at 18:37, To
drop support for all Django versions before the
> LTS, check their package with the LTS using python -Wall and make the
> deprecation warning fixes, then seamlessly add support for the next version
> of Django.
>
> Does that make sense?
>
This makes sense to me. +1
Regards,
M
On Tue, Oct 20, 2015 at 3:02 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> 2015-10-20 5:04 GMT+02:00 Michael Manfre :
>
>> My long term plan is to switch out ADO for replaceable ODBC and FreeTDS.
>> This may follow the current pattern Aymeric
e work. Regardless of the decision,
the repo will be hosted on github.
Regards,
Michael Manfre
--
GPG Fingerprint: 74DE D158 BAD0 EDF8
keybase.io/manfre
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)&quo
ssuming no core
devs chime in with a -1, I'd say create a ticket and you and/or others can
start working on a pull request.
Regards,
Michael Manfre
On Sun, Oct 11, 2015 at 5:00 AM, John Michael Lafayette <
johnmichaelreed...@gmail.com> wrote:
> Python now has static type c
stgresql specific field should exist in
django.contrib.postgres.
Regards,
Michael Manfre
On Tue, Sep 22, 2015 at 8:40 AM, Collin Anderson
wrote:
> If anyone's curious, the mysql situation is as crazy as you might expect.
> :)
>
> The max is only determined only by the total row size
I agree with Shai. The database backend needs to be able to control this
feature.
Regards,
Michael Manfre
On Sun, Sep 6, 2015 at 12:48 PM, Shai Berger wrote:
> Hi,
>
> On Sunday 06 September 2015 13:06:18 Aymeric Augustin wrote:
> >
> > This will require ./runtest
I never liked the "easy pickings" flag either. Your proposed change would
be a good way to identify the technical ability required to make the
changes to Django. Should we have a separate drop down with options to
identify the non-technical (bikeshedding) difficulty of the ticket? There
are certain
+1 for making it doable for 3rd party apps.
Regards,
Michael Manfre
On Tue, Aug 18, 2015 at 12:49 PM, Anssi Kääriäinen
wrote:
> I'm still thinking we shouldn't integrate any new query syntax into
> 1.9. Instead lets make it easy to create 3rd party apps that offer
> differ
On Mon, Aug 3, 2015 at 9:25 AM, Podrigal, Aron
wrote:
>
> > - Do we want to allow extending this to defaults that are applied on
> every save (automatic database backed modified timestamps for example)?
>
> +1 for this one too.
>
This behavior would be a nice step toward computed (readonly) dat
As some one who has had to abuse .extra() at times to make mssql things
work, I support this approach.
On Fri, Jul 31, 2015 at 4:00 PM, Tim Graham wrote:
> I had in mind a documentation note like this:
>
> Use this method as a last resort
>
>
> This is an old API that we aim to deprecate at some
On Wed, Jul 29, 2015 at 11:42 AM, Podrigal, Aron
wrote:
> Hi Loic,
>
> Agree with having a db_default kwarg.
>
> I am not using multiple databases so no experiance with db routers. So how
> would should we handle routing between different databases when the
> db_default value is not compatible wi
27;t support it.
Regards,
Michael Manfre
On Tue, Jul 7, 2015 at 9:57 AM, wrote:
>
> Hi all,
>
> I'd like to know why this feature will be only available on postgres and
> not as a Field for any database, like this product? This Field would be
> very usefull for many users I th
, and both
> warnings in 1.9.
>
> What do you think?
>
> --
> Loïc
>
> > On Jun 17, 2015, at 08:47, Josh Smeaton wrote:
> >
> > I'm also +1 on the proposal as it stands, and neutral on when the semver
> versioning should begin.
> >
> > On
I'm +1 on the Google doc proposal and like Markus, I support relabeling 1.9
to 2.0 to line the versions up with the new paradigm without the X.1 LTS
oddball.
Regards,
Michael Manfre
On Tue, Jun 16, 2015 at 12:34 PM, Collin Anderson
wrote:
> I also like the gdoc as it is. (1.8 LTS,
I like Colin's proposed schedule.
Regards,
Michael Manfre
On Thu, Jun 11, 2015 at 1:12 AM, Anssi Kääriäinen
wrote:
> +1 to Collin's release schedule.
>
> This schedule should make it extremely easy to support "develop using
> latest release, maintain using latest LT
This group is for the discussion of developing the Django framework.
Discussions and questions related to using Django should take place on the
django-users group.
Regards,
Michael Manfre
On Mon, Jun 1, 2015, 7:11 AM Swapnil Bhadade
wrote:
> Which are Django packages for full stack developm
on
the post. The topic of batch deletion signaling has come up before, but I
don't remember the outcome (or whether it was on here or IRC). I'll try to
find it and report back when I get to a more capable device.
Regards,
Michael Manfre
On Thu, May 7, 2015 at 7:36 PM, Antoine Cat
this issue.
Regards,
Michael Manfre
On Tue, May 5, 2015 at 8:52 PM, Paulo Maciel
wrote:
> I am returning the query Something.objects.all().order_by(Lower('name'))
> but the order is not respecting names that start with accent, causing these
> results appear at the end of
I like the alias.
On Fri, May 1, 2015 at 5:58 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> `python -m django` as a alias for `django-admin` sounds good.
>
> --
> Aymeric.
>
>
>
> On 30 avr. 2015, at 19:15, Ryan Hiebert wrote:
>
> https://github.com/django/django/pull/4588
#x27;s useful being able to modify the models that ship with Django.
E.g. increasing the size of user name field.
Regards,
Michael Manfre
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubs
On Sat, Apr 4, 2015 at 12:56 PM, Thomas Tanner wrote:
> I think rare LTS releases and frequent (6month) incremental upgrades are
> a good compromise.
> Third-party packages should support LTS releases and at least the latest
> Django version. They may drop support for earlier non-LTS releases.
>
uses to write
the model data.
Regards,
Michael Manfre
On Tue, Mar 10, 2015 at 11:56 AM, Collin Anderson
wrote:
> Hi All,
>
> We recently added database introspection of defaults for purposes of
> testing migrations.
>
>
> https://github.com
-1 on silently changing the field definition. At best this would result in
an unnecessary migration when the error is discovered. Django should error
out with a message that the composite field definition is invalid.
Regards,
Michael Manfre
On Sun, Mar 8, 2015 at 12:29 PM, Thomas Stephenson
ybePoint(...):
>has_point = models.BooleanField()
>point = Point()
>
> because of the inheritance limitations (which I might have to lift in the
> medium-long term anyway, but which I'd like to preserve for as long as
> possible to keep the initial implementation and API
As the others have already stated, patience is required if you want
meaningful feedback.
Have you thought about how CompositeFields and SubFields will interact with
migrations?
Regards,
Michael Manfre
On Wed, Mar 4, 2015 at 8:16 AM, Thomas Stephenson wrote:
> Considering the past
better than
having the extra complexity of using stored procedures in a Django project.
Regards,
Michael Manfre
On Fri, Feb 27, 2015 at 2:46 PM, Tom Evans wrote:
> On Fri, Feb 27, 2015 at 3:19 PM, aRkadeFR wrote:
> > What do you mean by a single roundtrip?
>
> He means aski
It's reasonable to support backend specific aggregate functions. The
database backend API contains
BaseDatabaseOperations.check_expression_support for this exact reason. Feel
free to create the ticket.
Regards,
Michael Manfre
On Sat, Feb 7, 2015 at 9:00 AM, Andriy Sokolovskiy (coldmind) <
test
suite, but that is something that should probably happen regardless of
parallelization.
I'm imagining database backends being able to control whether or not they
support parallelization and if each process needs its own database.
Regards,
Michael Manfre
On Fri, Feb 6, 2015 at 11:05 A
The situation you described was definitely a learning experience for your
company. Your strong opinion in favor of tuples is also noted.
For the various reasons stated in this thread, I'm still +1 for lists.
Regards,
Michael Manfre
On Mon, Jan 19, 2015 at 3:13 PM, Andreas Kahnert wrote:
For completeness, I'm Michael Manfre and have been the maintainer of
Django-mssql [1] for the last 6+ years. Future releases of Django-mssql
will officially support a single version of Django. Support for legacy
versions of Django will be maintained if it requires little effort.
Work on D
+1 to delaying the freeze to get this feature fully in place, especially
since 1.8 will be an LTS release. Is there precedent to doing a freeze with
an exemption for an in progress feature? If so, that is another option to
an outright extension.
Regards,
Michael Manfre
On Sat, Jan 3, 2015 at 8
Thanks for the explanation. It makes sense to remove select_template.
Regards,
Michael Manfre
On Sun, Dec 28, 2014 at 3:53 AM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Hi Michael,
>
> > On 28 déc. 2014, at 07:12, Michael Manfre wrote:
> >
>
tensely as live sites?
Regards,
Michael Manfre
On Sat, Dec 27, 2014 at 5:59 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:
> Hello,
>
> My twelfth update is online:
> https://myks.org/en/multiple-template-engines-for-django/#2014-12-28
>
> It com
+1 for lists.
On Wed, Dec 17, 2014 at 3:54 PM, Carl Meyer wrote:
>
> On 12/17/2014 01:48 PM, Aymeric Augustin wrote:
> > I’m about to introduce a new setting that is a sequence of things,
> TEMPLATES, and I have to decide whether it will be a tuple of a list.
> >
> > Unfortunately Django is very
is if you wanted to support multiple active sessions using
different authentication backends for the same user object.
Regards,
Michael Manfre
On Sat, Dec 13, 2014 at 4:28 AM, Roman Akopov wrote:
>
> Tim,
>
> It's not about the benefit, it's about the possibility. The one
Please open a ticket for this.
On Fri, Dec 12, 2014 at 9:11 AM, Bruno Ribeiro da Silva <
bruno.dev...@gmail.com> wrote:
> Hey everyone,
>
> I just found out that the new schemes option of URLValidator causes
> incompatible changes for people who were using custom regex to restrict
> schemes. Coul
LTS?
Regards,
Michael Manfre
--
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...@googlegro
usage, e.g.
URLs, but there is no reason to enforce this requirement in all uses of the
data because not everyone will expose a UUID in a URL.
-1 from me.
Regards,
Michael Manfre
On Sat, Dec 6, 2014 at 11:31 AM, Radek Svarz wrote:
> Hi, I am glad to see the UUID field coming to 1.8
>
>
Requiring fewer moving parts for small sites is definitely an improvement.
+1 to Collin's plan.
Regards,
Michael Manfre
On Fri, Dec 5, 2014 at 2:02 AM, Loïc Bistuer wrote:
> I'm +1 on this plan, "native" support for wsgi.file_wrapper makes a lot of
> sense.
>
>
g it along to the parent.
I think it's safe to say that this functionality is unlikely to find its
way in to Django, but if you have questions about the custom database
backend approach, feel free to contact me.
Regards,
Michael Manfre
--
You received this message because you are subscribed t
On Tue, Nov 18, 2014 at 7:42 PM, Josh Smeaton
wrote:
> To me, "sane default" means django should not silently alter the query to
> provide a LIMIT when it is not asked for.
>
> I have also run into situations where doing a .count() or iterating a full
> table has broken the application, or put to
needed when using the Admin. E.g. write custom ModelAdmins or
admin filters that restrict the resultset size.
I don't think Django should automatically limit these queries.
Regards,
Michael Manfre
On Tue, Nov 18, 2014 at 7:58 AM, Rick van Hattem wrote:
> Hi guys,
>
> As it is right
improvements, backwards incompatible changes are not likely to
happen. There is a huge cost involved with forcing everyone to update their
templates. Ideas on improvements that are backwards compatible would be
welcomed by many!
Regards,
Michael Manfre
On Mon, Nov 17, 2014 at 9:17 PM, wrote:
> He
Overriding get_db_prep_lookup seems like it would cause problems. Even if
were only registered when Oracle is in use, that would make multi-db with
Oracle as one of the backends problematic.
On Sat, Nov 15, 2014 at 5:46 PM, Josh Smeaton
wrote:
> Clever. I don't mind this approach at all. Will th
On Wed, Nov 5, 2014 at 7:53 PM, Shai Berger wrote:
> On Wednesday 05 November 2014 17:29:20 Michael Manfre wrote:
> > We can change the internal type of SlugField for option 1 based upon
> > whether or not the field should be unicode. Whether or not an existing
> > backend s
like an option to SlugField and I feel
> UnicodeSlugField is a bit ugly. If however we find an example where
> Michael's point is valid (an external 3rd party backend which uses ascii
> chars for SlugField now) then we should go with that.
>
> On 5 November 2014 03:20, Michael Ma
Should the unicode validated field (either options) have a different
internal type for the sake of 3rd party database backends? I'm not sure if
any currently store SlugFIeld in an ascii char datatype and would need an
easy way to differentiate.
Regards,
Michael Manfre
On Tue, Nov 4, 2014 at
same
disparity that 3rd party database backends faced, what are your thoughts on
having the jinga2 engine maintained outside of core? This would leave only
the string template reference implementation and the DTL in the core.
Regards,
Michael Manfre
On Sat, Nov 1, 2014 at 6:30 PM, Aymeric Aug
s someone who has used a very large number of stored procedures with
Django, I am a solid -1 on adding a generic "magic" layer to Django. Stored
procedures are purpose built. Their python usage should also be purpose
built to match the various combinations of input/output parameters, return
llowing to provide init kwargs.
MIDDLEWARE_CLASSES = (
'django.middleware.clickjacking.XFrameOptionsMiddleware',
('django.middleware.security.SecurityMiddleware',
{'content_type_nosniff': True, 'xss_filter': True}),
)
Regards,
Michael Manfre
--
You recei
n a day for the exact reason
brought up. The visible warnings could state why it is a good idea to
increase the duration, after it is tested in production.
Regards,
Michael Manfre
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To
ld argue it harms
> readability and the use of settings in general unless it's actually
> required.
>
Auto merging dicts is the wrong approach. Staging.py should contain exactly
what it appears to contain, SECURITY_MIDDLEWARE with a single key defined.
If some one needs to tweak one of the valu
On Thu, Aug 28, 2014 at 8:44 AM, Tim Graham wrote:
> I've implemented the ability to register "deployment checks" by adding
> deploy=True to register: @register("tag_name", deploy=True). These checks
> are only run if you pass the --deploy flag to check. So in development you
> can run `manage.py
in
its own test suite.
Regards,
Michael Manfre
On Sun, Aug 17, 2014 at 2:52 AM, Roger Hunwicks
wrote:
> I'm doing some refactoring of a Django app and I want to make sure that I
> don't introduce any really poorly performing pages as a result of poor
> queries.
>
> I wa
This mailing list is for the development of Django. Please direct questions
about how to use Django to the django-users mailing list.
Regards,
Michael Manfre
On Aug 7, 2014 12:06 PM, "Héctor Urbina" wrote:
> Hello,
>
> I'm developing a django project for my office, a
On Wed, Aug 6, 2014 at 8:59 PM, Josh Smeaton wrote:
> In that case, is it easy enough to support github oauth + the current trac
> auth concurrently? If a user chooses to go through the harder path, that's
> fine.
>
> I like the idea of using github oauth. Password managers usually have a
> miser
st you could do is generate the SQL from the migrations and manually
apply to the database.
Regards,
Michael Manfre
--
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
>
This is also used by 3rd party apps that support multiple versions of
Django with a single code base.
Regards,
Michael Manfre
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To unsubscribe from this group and stop receivi
Python packaging is definitely a lot better than it was and starting to
move the contribs to their own repos and packages would be a good thing to
do.
Regards,
Michael Manfre
On Fri, Jul 11, 2014 at 8:15 PM, Josh Smeaton
wrote:
> I think the "blessed packages" idea is a good one
each compile. To me, it seems much more elegant to duck type the
nodes as they're being compiled, instead of a giant import and monkey patch
setup function.
Regards,
Michael Manfre
[1] http://docs.sqlalchemy.org/en/rel_0_9/core/compiler.html
On Tue, Jul 1, 2014 at 11:32 AM, Anssi Kääriäine
backend needs to support those, too.
>
All of the subclasses are going to inherit SQLCompiler.compile and do the
same exact logic. I don't understand what problem is caused by overriding
compile that is solved by a function call to compile on some other class.
Regards,
Michael Manfre
--
work for two conflicting needs.
Regards,
Michael Manfre
On Wed, Jun 18, 2014 at 8:31 PM, Josh Smeaton
wrote:
> manfre has raised some issues about registering implementations in IRC. I
> had been assuming that AppConfigs could be used for backends to register
> their changes, but t
of these introspect features too. I'm not sure whether it makes
more sense to put assertFieldType on DatabaseFeatures or
DatabaseIntrospection.
[1]
https://github.com/django/django/blob/master/tests/inspectdb/tests.py#L36
Regards,
Michael Manfre
>
> >
> > Backwards-compatibi
ent". If people
feel strongly about staying on a no longer supported version of Oracle,
then they can either stick with an older version of Django or create
django-decrepit-oracle.
Django should strip this legacy code.
Regards,
Michael Manfre
On Sat, Jun 14, 2014 at 10:01 PM, Alex Gaynor wr
The feature was added by Aymeric for django-pymssql, which needs the
feature.
Regards,
Michael Manfre
On Thu, Jun 12, 2014 at 6:17 PM, Shai Berger wrote:
> Hi all,
>
> Bug #22816[1] is a test failure on Oracle. It was caused by the
> introduction
> of the "can_intro
That ticket seems to address issues with initial_data and not necessarily
deal with fixtures that are loaded for a specific TestCase. I do agree that
we should encourage people to not use fixtures and build their test data
within the scope of the test or the TestCase.
Regards,
Michael manfre
On
for 3rd party
backends to flag as not supported or be able to tweak the underlying SQL.
The most likely tweak would be renaming the function to match the specifics
of the database. I have to do this for some of the aggregation functions,
so it's safe to assume that some database might need to do
Each expression must be able to define it's own ordering because order_by
allows you to define a sort based upon multiple expressions.
On Mon, Jun 9, 2014 at 4:00 PM, Daniel Moisset
wrote:
> I see everyone trying to put the direction (ascending vs decending) inside
> the expression, while it's
1 - 100 of 202 matches
Mail list logo
