Re: Activity Reports

[John-Scott]

Hi Angelo,

Just checking back in to see what the latest thinking is on replacing the 
cmsplugin_filer_* plugins as far as deprecation timeline and possible paths 
for migrating to the newer djangocms-* plugins? 

I haven't followed development on the new plugins closely so apologies if 
this has been answered/solved elsewhere.

Thanks!
John-Scott

On Sunday, September 11, 2016 at 11:25:03 PM UTC-7, Angelo Dini wrote:
>
> Hello @john
>
> Yes we want to replace cmsplugin-filer with more specific plugins 
> following the Python Zen "Do one thing, and that good". For that matter we 
> are working on cleanup/improving some existing plugins to replace 
> cmsplugin-filer:
>
> - cmsplugin_filer_file > djangocms-file
> - cmsplugin_filer_folder > djangocms-file
> - cmsplugin_filer_image > djangocms-picture
> - cmsplugin_filer_link > djangocms-link
> - cmsplugin_filer_teaser > djangocms-teaser (though we do not update it 
> for now)
> - cmsplugin_filer_video > djangocms-video
>
> This will mainly help us ship djangocms-installer and the default 
> installation on Aldryn with good and clean base plugins. Next step will be 
> to provide facilities to migrate older projects to these new plugins. After 
> that we will deprecate the old ones (will take some months though). We will 
> publish blog posts prior to this scenario :)
>
>

-- 
Message URL: 
https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id
Unsubscribe: send a message to 
django-cms-developers+unsubscr...@googlegroups.com
--- 
You received this message because you are subscribed to the Google Groups 
"django CMS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-cms-developers+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/django-cms-developers/c1c299c1-d3ff-4e9b-8a98-c3fd4c3d0e37%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Pre-DEP: Meta.without_primary_key (related to CompositeFields)

[Roger Gammans]

Hi,

This would be useful for us too ; this is our use-case, again this is a
legacy schema which are rebuilding the system to use django, but there
are some models which we are using composite-pk support for due to the 
following. Having these feature many we could use a vanilla django.(eg
one without local patches)

Many of the table in our system are effectively, what django refers to
a through table. Eg, the join table in a many-2-many relationship , or
more often then not multi-join.  We almost always fetch by a a the 
set of joined PKs and those have been used a composite primary key on
the table. 

In this use case we are accepting not having admin tables as in many of
them are computed detail tables, but we still have uniqueness
guarantees at the SQL level since the Db still has the tables defined
with a PK.

Django's query builder as standard cannot interact with these tables,
adding this option will allow us to code model which partially capture
the semantics and build queries against them. I don't think we lose the
ability to use get() as there is still a uniqueness guarantee on the
table; it just it is partially hidden from the orm .

In some cases these are our largest tables with 10^7 or even 10^8 rows,
so adding an additional field is not undertaken lightly. We also have
an additional restriction in that the legacy code is still active is
some part of our system and still need to interact with these tables as
well.

I hope that might explain one way this option could be helpful.

On Tue, 2017-05-23 at 11:31 +0300, Shai Berger wrote:
> Hi,
> 
> Thank you for making this suggestion.
> 
> It is my guess that allowing pk-less models will place quite a burden
> on many 
> parts of Django, which assume a PK exists. There may also be other
> solutions 
> to the problem you raise -- e.g. changing the legacy table to add a
> PK, 
> perhaps while providing a pk-less view to any legacy systems which
> need to 
> access it.
> 
> In general, SQL database tables without any uniqueness guarantee are
> an 
> antipattern, which I don't believe Django should support. The
> question remains 
> how much such a feature can be made to contribute towards composite
> keys.
> 
> All in all, I would like to know more about your use case -- if you
> are going 
> to have no get/delete, no Admin, no updating save, how exactly are
> you going 
> to use these models? As you may be aware, since the Meta API
> formalization, it 
> is possible to create pseudo-models which are good enough for many
> purposes, 
> without changing Django and with much less strict adherence to "real"
> models' 
> behavior. Perhaps that is the way to go?
> 
> HTH,
> Shai.
> 
> On Monday 22 May 2017 21:50:07 sky.duv...@moveon.org wrote:
> > Hi,
> > 
> > We have several legacy database tables that don't have primary
> keys. With
> > older versions of Django, we've hacked it by lying about a field
> that was
> > not a primary key but recent Django versions validate pks more
> strictly.
> > 
> > Some (but not all) of our legacy tables have multiple primary keys
> -- i.e.
> > are unique only across a few fields.  This harks to the
> CompositeField work
> > and discussion [0].
> > 
> > But CompositeFields are not enough for us, some of our tables are
> > essentially append-only, and have no uniqueness constraints across
> any/all
> > fields.  It also seems like CompositeField has stalled several
> times
> > precisely because we are spiking to a very complex end goal.
> > 
> > I'd like to propose, both as an incremental step to CompositeFields
> and
> > something useful in itself, a model Meta option for
> `without_primary_key`
> > -- if Meta.without_primary_key=True then it would turn off the
> complaints
> > during model validation, etc.  One might object that things like
> > get/delete/caching can't work with that model.  However those
> features
> > can't be supported in tables without a primary key anyway.
> > 
> > Incrementally, after without_primary_key is implemented/supported,
> we could
> > then add features for models without_primary_key but also has a
> > Meta.unique_together value across some fields -- i.e. start trying
> to
> > support inheritance and/or ForeignKey references to those tables,
> building
> > up support.
> > 
> > I've started looking at how deep a change this would be, and
> believe it's
> > pretty tractable.
> > Before I get too involved with a DEP and PR, what do people think?
> > 
> > /sky
> > 
> > [0] Most recent thread:
> > https://groups.google.com/forum/#!searchin/django-developers/primar
> y$20keys
> > |sort:date/django-developers/wakEPFMPiyQ/ke5OwgOPAQAJ
> 

-- 
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 

Re: assertRaises vs. assertRaisesMessage

[Shai Berger]

Hi,

I apologize for re-raising a thread that's mostly done and decided, but I just 
ran into [1] where it says:

"""
Note

Exception messages are not part of the Python API. Their contents may change 
from one version of Python to the next without warning and should not be 
relied on by code which will run under multiple versions of the interpreter. 
"""

I don't think that's enough to overturn the decision, but I thought this 
should be noted in this thread.

[1] https://docs.python.org/3/reference/executionmodel.html#exceptions

Re: Connecting to postgresql database

[Tom Forbes]

Hi Anthony, this mailing list is for the development of Django only. Please
post questions like this to django-users or ask in the #django freenode IRC
channel, and not in this mailing list.

As for your issue: the exception message explains exactly what the issue
is. Try running 'pip install --upgrade psycopg2'.

On 25 May 2017 12:48, "Anthony Njogu"  wrote:

I have been trying to connect my project to postgresql db. my django doesnt
understand the 'python manage.py migrate' command and every time I try
using syncdb it gives me this error;

Traceback (most recent call last):
  File "manage.py", line 10, in 
execute_from_command_line(sys.argv)
  File "/usr/local/lib/python2.7/dist-packages/Django-1.11.1-
py2.7.egg/django/core/management/__init__.py", line 363, in
execute_from_command_line
utility.execute()
  File "/usr/local/lib/python2.7/dist-packages/Django-1.11.1-
py2.7.egg/django/core/management/__init__.py", line 337, in execute
django.setup()
  File 
"/usr/local/lib/python2.7/dist-packages/Django-1.11.1-py2.7.egg/django/__init__.py",
line 27, in setup
apps.populate(settings.INSTALLED_APPS)
  File "/usr/local/lib/python2.7/dist-packages/Django-1.11.1-
py2.7.egg/django/apps/registry.py", line 108, in populate
app_config.import_models()
  File "/usr/local/lib/python2.7/dist-packages/Django-1.11.1-
py2.7.egg/django/apps/config.py", line 202, in import_models
self.models_module = import_module(models_module_name)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
  File "/usr/local/lib/python2.7/dist-packages/Django-1.11.1-
py2.7.egg/django/contrib/auth/models.py", line 4, in 
from django.contrib.auth.base_user import AbstractBaseUser,
BaseUserManager
  File "/usr/local/lib/python2.7/dist-packages/Django-1.11.1-
py2.7.egg/django/contrib/auth/base_user.py", line 52, in 
class AbstractBaseUser(models.Model):
  File "/usr/local/lib/python2.7/dist-packages/Django-1.11.1-
py2.7.egg/django/db/models/base.py", line 124, in __new__
new_class.add_to_class('_meta', Options(meta, app_label))
  File "/usr/local/lib/python2.7/dist-packages/Django-1.11.1-
py2.7.egg/django/db/models/base.py", line 330, in add_to_class
value.contribute_to_class(cls, name)
  File "/usr/local/lib/python2.7/dist-packages/Django-1.11.1-
py2.7.egg/django/db/models/options.py", line 214, in contribute_to_class
self.db_table = truncate_name(self.db_table, connection.ops.max_name_
length())
  File "/usr/local/lib/python2.7/dist-packages/Django-1.11.1-
py2.7.egg/django/db/__init__.py", line 33, in __getattr__
return getattr(connections[DEFAULT_DB_ALIAS], item)
  File 
"/usr/local/lib/python2.7/dist-packages/Django-1.11.1-py2.7.egg/django/db/utils.py",
line 211, in __getitem__
backend = load_backend(db['ENGINE'])
  File 
"/usr/local/lib/python2.7/dist-packages/Django-1.11.1-py2.7.egg/django/db/utils.py",
line 115, in load_backend
return import_module('%s.base' % backend_name)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
  File "/usr/local/lib/python2.7/dist-packages/Django-1.11.1-
py2.7.egg/django/db/backends/postgresql/base.py", line 36, in 
raise ImproperlyConfigured("psycopg2_version 2.5.4 or newer is
required; you have %s" % psycopg2.__version__)
django.core.exceptions.ImproperlyConfigured: psycopg2_version 2.5.4 or
newer is required; you have 2.4.5 (dt dec mx pq3 ext)

-- 
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/9eb33c85-5b23-4598-b66b-9c18cb731d86%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/CAFNZOJNhpdZwtiXSxNqDM6zvN4Q6OxNmEw3Ooc%3DsHr0y_xNP1w%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Connecting to postgresql database

[Anthony Njogu]

I have been trying to connect my project to postgresql db. my django doesnt 
understand the 'python manage.py migrate' command and every time I try 
using syncdb it gives me this error;

Traceback (most recent call last):
  File "manage.py", line 10, in 
execute_from_command_line(sys.argv)
  File 
"/usr/local/lib/python2.7/dist-packages/Django-1.11.1-py2.7.egg/django/core/management/__init__.py",
 
line 363, in execute_from_command_line
utility.execute()
  File 
"/usr/local/lib/python2.7/dist-packages/Django-1.11.1-py2.7.egg/django/core/management/__init__.py",
 
line 337, in execute
django.setup()
  File 
"/usr/local/lib/python2.7/dist-packages/Django-1.11.1-py2.7.egg/django/__init__.py",
 
line 27, in setup
apps.populate(settings.INSTALLED_APPS)
  File 
"/usr/local/lib/python2.7/dist-packages/Django-1.11.1-py2.7.egg/django/apps/registry.py",
 
line 108, in populate
app_config.import_models()
  File 
"/usr/local/lib/python2.7/dist-packages/Django-1.11.1-py2.7.egg/django/apps/config.py",
 
line 202, in import_models
self.models_module = import_module(models_module_name)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
  File 
"/usr/local/lib/python2.7/dist-packages/Django-1.11.1-py2.7.egg/django/contrib/auth/models.py",
 
line 4, in 
from django.contrib.auth.base_user import AbstractBaseUser, 
BaseUserManager
  File 
"/usr/local/lib/python2.7/dist-packages/Django-1.11.1-py2.7.egg/django/contrib/auth/base_user.py",
 
line 52, in 
class AbstractBaseUser(models.Model):
  File 
"/usr/local/lib/python2.7/dist-packages/Django-1.11.1-py2.7.egg/django/db/models/base.py",
 
line 124, in __new__
new_class.add_to_class('_meta', Options(meta, app_label))
  File 
"/usr/local/lib/python2.7/dist-packages/Django-1.11.1-py2.7.egg/django/db/models/base.py",
 
line 330, in add_to_class
value.contribute_to_class(cls, name)
  File 
"/usr/local/lib/python2.7/dist-packages/Django-1.11.1-py2.7.egg/django/db/models/options.py",
 
line 214, in contribute_to_class
self.db_table = truncate_name(self.db_table, 
connection.ops.max_name_length())
  File 
"/usr/local/lib/python2.7/dist-packages/Django-1.11.1-py2.7.egg/django/db/__init__.py",
 
line 33, in __getattr__
return getattr(connections[DEFAULT_DB_ALIAS], item)
  File 
"/usr/local/lib/python2.7/dist-packages/Django-1.11.1-py2.7.egg/django/db/utils.py",
 
line 211, in __getitem__
backend = load_backend(db['ENGINE'])
  File 
"/usr/local/lib/python2.7/dist-packages/Django-1.11.1-py2.7.egg/django/db/utils.py",
 
line 115, in load_backend
return import_module('%s.base' % backend_name)
  File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module
__import__(name)
  File 
"/usr/local/lib/python2.7/dist-packages/Django-1.11.1-py2.7.egg/django/db/backends/postgresql/base.py",
 
line 36, in 
raise ImproperlyConfigured("psycopg2_version 2.5.4 or newer is 
required; you have %s" % psycopg2.__version__)
django.core.exceptions.ImproperlyConfigured: psycopg2_version 2.5.4 or 
newer is required; you have 2.4.5 (dt dec mx pq3 ext)

-- 
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/9eb33c85-5b23-4598-b66b-9c18cb731d86%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Integrate dj-database-url into Django

[Florian Apolloner]

On Thursday, May 25, 2017 at 9:46:56 AM UTC+2, Aymeric Augustin wrote:
>
> I'm wary of possible security ramifications: if we do this, changing a 
> configuration value will import an arbitrary module, which could make it 
> easier to run arbitrary code in some scenarios. I don't have a clear threat 
> model in mind here, though.
>

One possibility would be to use entrypoints in setuptools, this way 3rd 
party backends could specify a name which then has a fixed & verified 
import path.

-- 
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/576a3961-6c84-4438-b434-4beaddab38b2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: migration lock file implementation

[Adam Johnson]

I agree, it really depends on your project's workflow and organization as
to how often you see migration conflicts and whether this is the right way
to show them to users. Creating lock files in django core would just add
confusion for 99% of projects.

On 24 May 2017 at 23:03, Florian Apolloner  wrote:

> On Wednesday, May 24, 2017 at 9:42:20 PM UTC+2, Andrew Godwin wrote:
>>
>> I am personally unsure about this - it's extra overhead for smaller
>> Django sites, and something that larger teams could easily adopt themselves.
>>
>
> Yeah, I do not see an immediate need for this either.
>
> --
> 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/522df540-899e-4c18-a101-
> d14a9f6535d9%40googlegroups.com
> 
> .
>
> For more options, visit https://groups.google.com/d/optout.
>



-- 
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 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/CAMyDDM0s%2BT-5XZUv-ecQ50%3Dd8kLvXYjUPko0RRuvQA%2BaW3byrw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: Integrate dj-database-url into Django

[Aymeric Augustin]

Hello,

I'm wondering what the exact definition of the URL format is. Is it specified 
somewhere? Or is it just:

[engine]://[username]:[password]@[host]:[port]/[name]

where we create arbitrary [engine] values in an ad-hoc fashion?

> On 24 May 2017, at 21:21, Tom Forbes  wrote:
> 
> My two cents: connection strings/database URI's are a feature I've sorely 
> missed in Django.
> 
> Built-in functionality to convert environment variables like 
> DJANGO_DB_DEFAULT (or more generally DJANGO_DB_*key*) into the relevant 
> DATABASE setting would make some deployment situations a lot simpler. 
> Currently, unless you use dj-database-uri you have to define a bunch of 
> ad-hoc DB_USER/DB_PASSWORD etc env variables and price the dictionary 
> together yourself.

Fully agreed. While relatively minor, it's an annoyance.

> How does this library complex keys like OPTIONS, TEST or DEPENDENCIES?

I don't think it's reasonable to cram them in a URL.

dj-database-url allows passing options as extra keyword arguments. Other values 
should be explicitly added in the settings module, by updating the dict 
generated from the URL.

> To help support third part backends: perhaps the scheme portion of the URI 
> could be either a relative import from django.db.backends or an absolute 
> import to a third party library? It seems URI schemes can have dots and 
> underscores in them, so they can be python package paths.
> 
> I.e sqlite3://xyz would resolve go django.db.backends.sqlite3, but 
> sqlserver_ado://xyz would resolve to the third party django-mssql engine via 
> an absolute import.

I'm wary of possible security ramifications: if we do this, changing a 
configuration value will import an arbitrary module, which could make it easier 
to run arbitrary code in some scenarios. I don't have a clear threat model in 
mind here, though.

I'd rather specify the database engine explicitly when calling dj-database-url 
if it's a third-party engine. There's an open question about what to do with 
the [engine] part of the URL in that case. Ignoring it entirely is the easiest.

Best regards,

-- 
Aymeric.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/A0870D90-75DE-496B-A838-AC7D7488A67D%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.