more time down that path, is there something obvious we might be
missing?
2. What do you think of this approach with hooks (pre and post
"add_operation")?
3. Do you think it would be a useful feature for other third party apps as
well (not just content types and permissions)?
Than
I encountered a similar issue recently, but with auth permissions.
It is described here: https://code.djangoproject.com/ticket/29843
On Wednesday, October 3, 2018 at 1:01:37 PM UTC+2, Marcin Nowak wrote:
>
> Hello.
>
> There is a huge issue with content types framework. The da
s between different environments.
>
> the only other way currently would be to run a `migrations.RunSql` query
>> which may look different based on the database used.
>>
>
> RunSQL is not the solution for db agnostic operations. It may be only used
> within a project, because db engin
but should be applied "at the right time".
> Content type is an opt-in feature since you can remove it from
> `INSTALLED_APPS`.
>
I know, but it is required by contrib.auth. I saw no project depending on
something else, so CT is optional.. but theoretically ;)
>
>- cr
o the nature
and importance of the data and relational databases, and systems dependent
on the db).
But RunSQL is a handful operation, because SQL is a natural language for db
management. I'm doing many raw sqls in migrations.
> Two things are wrong:
>
>- automatic creation of cont
tional databases, and systems dependent
on the db).
But RunSQL is a handful operation, because SQL is a natural language for db
management. I'm doing many raw sqls in migrations.
> Two things are wrong:
>
>- automatic creation of content types
>
> Why is it wrong to automa
run
a `migrations.RunSql` query which may look different based on the database
used.
Two things are wrong:
- automatic creation of content types
Why is it wrong to automatically create a content type? Content type is an
opt-in feature since you can remove it from `INSTALLED_APPS
never criticised a person directly.
> Starting with "There is a huge issue with content types framework" isn't a
> good way to motivate them.
>
>
But there is an issue with content types framework (not with it's authors).
> Speaking for myself, I would be
Hello Marcin,
I assume you're writing to this list because you would like other Django
contributors to cooperate in order to fix this issue. Starting with "There is a
huge issue with content types framework" isn't a good way to motivate them.
Speaking for myself, I wo
]
>
> Wouldn't a workaround be to call create_contenttypes() in a RunPython in
> your app's migration before inserting the data which depends on the content
> types?
>
>
Thanks, but as a workaround you can do almost everything. My post is about
proposal of fixing the
Wouldn't a workaround be to call create_contenttypes() in a RunPython in
your app's migration before inserting the data which depends on the content
types?
On Wed, 3 Oct 2018 at 12:01, Marcin Nowak wrote:
> Hello.
>
> There is a huge issue with content types framework.
Hello.
There is a huge issue with content types framework. The data is loaded
after every migration (post_migrate signal) automatically, and this
approach is against db data consistency.
The biggest problem is with data migrations, which are applied at the first
time (on clean database). Any
Oh! I see. I think I interpreted as "this would be a good utility module".
Small misunderstanding.
Even so, the mechanisms that cause Django to prompt for interaction are
within that method. To make another method to me indicates overriding the
one I just modified. But it's as I said I've only
My suggestion wasn't that update_contenttypes() couldn't be modified, but
rather that it might be better to expose the desired functionality as a
separate utility method to avoid having to explain in the documentation how
the interactive and force_remove keywords interact (probably the utility
Original closed ticket: https://code.djangoproject.com/ticket/24820
The content of it is as follows:
While removing models in one of my migrations, I was prompted by Django to
> input yes/no. For development, this is no problem. For automatic
> deployments it is.
>
> I want to know if there ex
rator objects.)
I like the idea because it follows the same pattern as request.POST but
supplements the behaviour to support arbitrary methods and content-types,
which is pretty core stuff for anyone trying to do any Web API stuff with
Django. Forcing the developer to drop do
On Sat, Nov 7, 2009 at 1:48 PM, J Meier wrote:
>
> I've implemented a nearly identical solution for this problem before,
> and while it worked, it felt dirty.
>
> It strikes me that the problem is to do with our "surrogate" primary
> key ids, which don't relate to the data at all. For most models
r a ContentType object is serialized.
>>
>> The problem with this approach is that hard-codes a single aspect of
>> serialization into the model. If someone has a different set of
>> requirements for serializing content types under particular
>> circumstances, they will be
On Nov 6, 3:48 pm, Russell Keith-Magee wrote:
> On Fri, Nov 6, 2009 at 11:41 AM, mattimust...@gmail.com
>
>
>
> wrote:
>
> >> In my minds eye, I have a vision of a serialization framework that
> >> would allow for registration of different serialization formats - not
> >> just JSON/XML, but th
On Fri, Nov 6, 2009 at 1:55 AM, Travis Cline wrote:
>
> On Nov 5, 10:21 am, Jacob Kaplan-Moss wrote:
>> That said, I do think Eric's suggestion of automatically introspecting
>> for unique/unique_together is the best idea I've seen yet. Well, the
>> best idea that doesn't require a ground-up rew
On Fri, Nov 6, 2009 at 11:41 AM, mattimust...@gmail.com
wrote:
>
>> In my minds eye, I have a vision of a serialization framework that
>> would allow for registration of different serialization formats - not
>> just JSON/XML, but the fields and internal structure of a JSON
>> fixture, etc. Descri
--
>>
>> The problem with this approach is that hard-codes a single aspect of
>> serialization into the model. If someone has a different set of
>> requirements for serializing content types under particular
>>
gt; keys for these objects aren't necessarily consistent after a syncdb,
> so fixtures can't reliably refer to auth permissions or content types.
> The problem is more general than these two apps specifically, but
> these two are the ones that most people get bitten by early on in th
exist).
>
> This sort of request has come up before, but I personally haven't worked
> on it yet, because it really needs a larger solution: if you are truly
> wanting to query content types all the time, you need to implement a
> cache for content-types or you are going to pay the
levant method (using add_to_class())
in there. See the code at the top of django/db/models/manipulators.py
for a similar usage (that is how we add default manipulators if none
exist).
This sort of request has come up before, but I personally haven't worked
on it yet, because it really needs a la
Jacob Kaplan-Moss wrote:
> Try this::
>
> from innovate.innovation.models import Innovation
> from django.contrib.contenttypes.models import ContentType
>
> i = Innovation.objects.get(id=1)
> ct = ContentType.objects.get_for_model(i)
Yeah, that's not so hard. I updated my
On 11/3/06 3:48 PM, Rob Hudson wrote:
> That way, any model I have will have that method available to easily and
> quickly get its content type.
Try this::
from innovate.innovation.models import Innovation
from django.contrib.contenttypes.models import ContentType
type.
I've been playing with apps that relate to content types more and this
seems like a useful thing to have.
I tried adding a method to my model along the lines of this:
def get_content_type(self):
cm = ContentTypeManager()
return cm.get_for_model(self)
But that f
Hi.
A while back I submitted a patch to re-enable the 'getContentType()'
functionality which was in 0.91
(and removed when content types got moved into contrib)
the solution adds a cached copy of the ContentType record onto a
model IF you have loaded the contenttype app into you
Jason Davies wrote:
> Luke Plant wrote:
> > In addition to your patch, I'd propose changing 'get_model_module()' to
> > 'get_model_class()' (also, your patch has a 'get_object', which should
> > be just 'get').
>
> OK. I've just noticed that the permissions stuff in
> django.contrib.auth depends
Luke Plant wrote:
> Jason Davies wrote:
>
> > 1. Get rid of the 'Package' model - is there any use for it now that
> > the magic has gone?
> > 2. Replace ContentType's 'package' and 'python_module_name' fields with
> > a 'model' field.
>
> +1 - the 'Package' table now seems to contain two columns
Jason Davies wrote:
> 1. Get rid of the 'Package' model - is there any use for it now that
> the magic has gone?
> 2. Replace ContentType's 'package' and 'python_module_name' fields with
> a 'model' field.
+1 - the 'Package' table now seems to contain two columns with
identical content. Just t
Jason Davies wrote:
> I propose:
> 1. Get rid of the 'Package' model - is there any use for it now that
> the magic has gone?
> 2. Replace ContentType's 'package' and 'python_module_name' fields with
> a 'model' field.
I've submitted a patch here: http://code.djangoproject.com/ticket/1280
djang
Hi,
I was just fiddling around trying to get comments working in
magic-removal when I came across this in
django.contrib.contenttypes.models:
def get_model_module(self):
"Returns the Python model module for accessing this type of
content."
return __import__('django.models.%s.
34 matches
Mail list logo
