for each field in the model you can specify the column name un the db, it
does have a default way of calculating that, but you can specify

in any case you can tell the django ORM that this field is not an int, it
is actually a foreign key, let me know if that works

what DB are you using? mysql?

On Tue, Mar 10, 2015 at 2:59 PM, Nan <ringe...@gmail.com> wrote:

>
> Thanks, Avraham -- I was planning to use inspectdb as a first step, and
> it's very handy in streamlining building models!
>
> But that doesn't even begin to solve the problem of how a GFK modeled
> differently than Django's ORM does can be used as an actual foreign key.
>
>
> On Sunday, March 8, 2015 at 1:07:56 PM UTC-4, Avraham Serour wrote:
>>
>> use inspectdb to start
>>
>> On Sun, Mar 8, 2015 at 5:31 PM, Nan <ring...@gmail.com> wrote:
>>
>>>
>>> Hi folks --
>>>
>>> I'm building out Django models to represent a legacy PHP app's database
>>> in order to throw together a quick admin panel.  Everything's working great
>>> except that the ORM of the other application represents generic relations
>>> slightly differently than Django's does.  I can't modify the DB schema
>>> because the legacy application has to continue to run.
>>>
>>> Django uses:
>>>
>>> int content_type_id
>>> int object_id
>>>
>>> The existing DB essentially uses:
>>>
>>> string model_class_name
>>> int object_id
>>>
>>> Is there a way to get Django's ORM to use these fields to represent a
>>> GFK relationship so I can use it in the admin?  I can add tables, just not
>>> modify existing ones.  Maybe an extra 1-to-1 mapping content types to
>>> legacy model names would help?  Maybe writing a GenericForeignKey
>>> subclass?  A quick look at the source suggests there are a lot of methods
>>> that will need to be overridden (by copy-pasting 40 lines and changing
>>> one), which doesn't sound like fun to maintain in the long run.
>>>
>>> Just wondering if anyone's done this before or has any tips before I
>>> dive in.
>>>
>>> Thanks!
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Django users" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to django-users...@googlegroups.com.
>>> To post to this group, send email to django...@googlegroups.com.
>>> Visit this group at http://groups.google.com/group/django-users.
>>> To view this discussion on the web visit https://groups.google.com/d/
>>> msgid/django-users/3ec838f1-34ff-46f1-9b94-d3b9ac905d19%
>>> 40googlegroups.com
>>> <https://groups.google.com/d/msgid/django-users/3ec838f1-34ff-46f1-9b94-d3b9ac905d19%40googlegroups.com?utm_medium=email&utm_source=footer>
>>> .
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at http://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/65c6f173-b407-465c-aecf-0c0a018050c6%40googlegroups.com
> <https://groups.google.com/d/msgid/django-users/65c6f173-b407-465c-aecf-0c0a018050c6%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAFWa6tKvv6K%3DYxnabSruaU-q%2BtPEqp17SE1Lh04%3DZfAVMoPZVg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to