Monday, July 29, 2013

Re: django workaround for multiple primary keys or sqlalchemy

Great thanks for the helpful reply!
I'll use the Django ORM like you suggested, that was my gut filling anyways..

Thanks!

On Monday, July 29, 2013 3:09:56 PM UTC-4, Justin Michalicek wrote:
I would go with the Django ORM and just add a unique_together for a multiple column uniqueness constraint.  That index won't be your primary key, but it will still be a unique index.  I've even gone as far as to use custom .sql files (which manage.py syncdb runs) and custom sql in South migrations to create highly customized things like a partial unique index (a Postgres specific thing) when necessary.

Going with SQLAlchemy is probably asking for trouble, especially if you're new both Django and SQLAlchemy.  Swapping SQLAlchemy in for the Django ORM was more common early in Django's lifetime when its ORM was not as robust as it is today.  By doing so you'll lose a number of things that currently "just work", which to me is one of strengths of Django - these things were made to work together and so I know they will work and will continue to work.  I suspect using SQLAlchemy is going to cause issues if you try to use any 3rd party Django apps as well.

On Monday, July 29, 2013 11:39:20 AM UTC-4, Guy Tamir wrote:
Hi all,

i'm fairly new to Django and i have a question regarding the best practice for a situation i've got.

I'm working on a new project and after designing my ERD I know i need a few tables to have multiple primary keys and one table with triple primary keys.

after reading about the subject online i found out that Django does not support this feature yet but there is a workaround which is to add a unique_together constraint (if i understand correct)
reading some more online there are recommendations for working with SQLAlchemy that does support the multiple primary key issue.

I have 2 questions regarding those issues:
1. if I use the django workaround will it later bite me in the ass performance wise and simply by not working correctly?
2. if i'll work with SQLAlchemy does that mean that i wont be able to work with django models and all that is derived from working like so?

whats the recommended practice for my situation?

Thanks all..

--
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+unsubscribe@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.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

No comments:

Post a Comment