Re: django workaround for multiple primary keys or sqlalchemy

[Tom Evans]

On Mon, Jul 29, 2013 at 10:04 PM, Bill Freeman  wrote:
> Its not clear to me whether unique_together will make there be an index, so
> it might be slow.

unique_together implies a multi part index - it's the only way it
could be reasonably implemented.

Cheers

Tom

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

Re: django workaround for multiple primary keys or sqlalchemy

[Guy Tamir]

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

Re: django workaround for multiple primary keys or sqlalchemy

[Bill Freeman]

Its not clear to me whether unique_together will make there be an index, so
it might be slow.


On Mon, Jul 29, 2013 at 3:09 PM, Justin Michalicek <jmichali...@gmail.com>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+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.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>

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

Re: django workaround for multiple primary keys or sqlalchemy

[Justin Michalicek]

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

django workaround for multiple primary keys or sqlalchemy

[Guy Tamir]

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

Re: Multiple Primary Keys

[Ramiro Morales]

On Wed, Mar 17, 2010 at 12:21 PM, ojayred <oredho...@gmail.com> wrote:
> Hello Users,
>
> I am new to using Django and so far, I like it. I have installed
> Django and want to use it with a pre-existing database. Several tables
> have multiple primary keys. How do I create the multiple primary keys
> in the model? I did use the inspectdb command to help me create the
> model because some tables have more than 25 columns.

Unfortunately it isn't supported. See:

http://docs.djangoproject.com/en/1.1/faq/models/#do-django-models-support-multiple-column-primary-keys

-- 
Ramiro Morales  |  http://rmorales.net

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Multiple Primary Keys

[ojayred]

Hello Users,

I am new to using Django and so far, I like it. I have installed
Django and want to use it with a pre-existing database. Several tables
have multiple primary keys. How do I create the multiple primary keys
in the model? I did use the inspectdb command to help me create the
model because some tables have more than 25 columns.  Also, can I run
an SQL module (*.sql file) from Django? Or any suggestions on how to
do so. Thank you for your input.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-us...@googlegroups.com.
To unsubscribe from this group, send email to 
django-users+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en.

Re: Multiple primary keys

[Lars Stavholm]

Leo wrote:
> Lars, have you made any progress on this?  I agree that only the

Sorry to say: no progress at all:(

> numeric types are interesting as multiple keys, so worrying about
> URL encoding is pointless (i.e., there's no reason to worry about
> supporting multiple arbitrary-string keys).

Well, pointless may be a little bit harsh. One of the previous
arguments was that a lot of effort has been spent on figuring
out a good way of using the URL's to match the django datamodel
and the human user, and the changes for the multiple primary key
would destroy the (pretty nice) URL scheme used today.

So I'd say: yes there's reason to worry about *how* to support
multiple primary keys (including arbitrary string keys), but
there's no reason what-so-ever not to implement it. The multiple
primary key feature would open up for loads of legacy database
applications. The possibilities for django on top of legacy
databases would be endless instead of gravely limited, as is
the case today.

Also, I've seen some work on a native GUI interface being
generated on top of a django db model, and sure enough, from
my point of view, with for example WxWindows, you could with
relative ease create native (multiplatform) GUI interfaces
using django.

Django + webappl + native GUI + python: does it get any better?

Except of course, for the multiple primary keys:(

> I'm trying to convince a team to use Django for new development
> on a large (1M+ records) existing database. The truth is it won't
> happen due to lack of this exact feature -- the existing database
> uses multiple (numeric) keys widely, in very conventional ways.

Well, it's common enough in the RDBMS world.

> When there are other non-Django interfaces still in use by users,
> adding special database id columns for Django's sake is unfeasible.

Very true. I've tried to figure out ways of cheating, finding some
sort of intermediate solution or what-not. No such luck. The only
solution here is to have django handle the typical multiple primary
keys situation.

Sorry to say, I'm not fluent in python, and definitely not in
django internals, otherwise I would have gone for it myself.

Short of that, if anyone's listening, I could do tests on this
subject. I have a good few both smaller and bigger legacy
databases that I would have loved to django-ify.

Cheers
/Lars


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Multiple primary keys

[Leo]

Lars, have you made any progress on this?  I agree that only the
numeric
types are interesting as multiple keys, so worrying about URL
encoding
is pointless (i.e., there's no reason to worry about supporting
multiple
arbitrary-string keys).

I'm trying to convince a team to use Django for new development
on a large (1M+ records) existing database.  The truth is it won't
happen
due to lack of this exact feature -- the existing database uses
multiple (numeric) keys widely, in very conventional ways.
When there are other non-Django interfaces still in use by users,
adding
special database id columns for Django's sake is unfeasible.

Leo






--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Multiple primary keys

[Lars Stavholm]

Thanks, Michael, I'll give it a try.
/Lars

Michael Radziej wrote:
> Hi Lars,
> 
> I found myself in a similar position, and I'm also coming from the database
> side ... funny ;-)
> 
> I have attached a small patch that solved the problem for me and might be a
> start for you, but be aware, it's more a crutch than a solution.
> 
> - this patch won't make it into the project, so you have to maintain it on
>   your own
> 
> - it doesn't try to work for the admin or for newforms (but made be working
>   for it), so I didn't have to deal with the admin URLs at all.
> 
> - it does not deal with creating databases or database introspection.
> 
> For a model with multiple primary keys, add an Meta class attribute
> `has_composite_primary_key_key=True`. Here's an example model with 
> multiple primary keys:
> 
> class Kundemail(UpdatelogMixin, models.Model):
> kunde = models.ForeignKey(Kunde, db_column='kunde', primary_key = True)
> dienst = DescriptorField(Descr, "dienst", db_column="dienst", primary_key 
> = True)
> person = models.ForeignKey(Person, db_column='person', primary_key = True)
> 
> class Meta:
> db_table = 'kundemail'
> has_composite_primary_key = True
> 
> So long,
> 
> Michael
> 
> 
> 
> 
> 
> From nobody Mon Sep 17 00:00:00 2001
> From: Michael Radziej <[EMAIL PROTECTED]>
> Date: Mon Aug 13 16:03:06 2007 +0200
> Subject: [PATCH] composite pkey
> 
> Refreshed patch composite-pkey.
> (Base: da455ae19930af1b4513b37de8bd8e9f68ec6c3d)
> (Last: 22c5ecf0407989824916f6b1676a4632c336a9d1)
> 
> ---
> 
>  django/core/management.py   |9 -
>  django/db/models/options.py |4 +++-
>  2 files changed, 11 insertions(+), 2 deletions(-)
> 
> base 0f7580c29c7e992e9a071d3df62260e0609c2c68
> last f7b6a55742bbf1ff867d841cdc17942fff357470
> diff --git a/django/core/management.py b/django/core/management.py
> index 
> 882ff6de323a45a718c4d84b592da8a1ecc7357e..7f11101e69490faca4dcaac1b6acd29454a6ab0b
>  100644
> --- a/django/core/management.py
> +++ b/django/core/management.py
> @@ -157,6 +157,7 @@ def _get_sql_model_create(model, known_models=set()):
>  opts = model._meta
>  final_output = []
>  table_output = []
> +composite_pkeys = []
>  pending_references = {}
>  for f in opts.fields:
>  col_type = f.db_type()
> @@ -172,7 +173,10 @@ def _get_sql_model_create(model, known_models=set()):
>  if f.unique and (not f.primary_key or backend.allows_unique_and_pk):
>  field_output.append(style.SQL_KEYWORD('UNIQUE'))
>  if f.primary_key:
> -field_output.append(style.SQL_KEYWORD('PRIMARY KEY'))
> +if opts.has_composite_primary_key:
> +composite_pkeys.append(f)
> +else:
> +field_output.append(style.SQL_KEYWORD('PRIMARY KEY'))
>  if tablespace and backend.supports_tablespaces and (f.unique or 
> f.primary_key) and backend.autoindexes_primary_keys:
>  # We must specify the index tablespace inline, because we
>  # won't be generating a CREATE INDEX statement for this field.
> @@ -196,6 +200,9 @@ def _get_sql_model_create(model, known_models=set()):
>  for field_constraints in opts.unique_together:
>  table_output.append(style.SQL_KEYWORD('UNIQUE') + ' (%s)' % \
>  ", 
> ".join([backend.quote_name(style.SQL_FIELD(opts.get_field(f).column)) for f 
> in field_constraints]))
> +if opts.has_composite_primary_key:
> +table_output.append(style.SQL_KEYWORD('PRIMARY KEY')+ ' (%s)' % \
> +", ".join([backend.quote_name(style.SQL_FIELD(f.column)) for f 
> in composite_pkeys]))
>  
>  full_statement = [style.SQL_KEYWORD('CREATE TABLE') + ' ' + 
> style.SQL_TABLE(backend.quote_name(opts.db_table)) + ' (']
>  for i, line in enumerate(table_output): # Combine and add commas.
> diff --git a/django/db/models/options.py b/django/db/models/options.py
> index 
> 7cccb611cf354d5e9d5288a05f7c788ee6a4fa52..60e050b2ddd3a26a4941ba5fb1706338699137a7
>  100644
> --- a/django/db/models/options.py
> +++ b/django/db/models/options.py
> @@ -15,7 +15,8 @@ get_verbose_name = lambda class_name: 
> re.sub('(((?<=[a-z])[A-Z])|([A-Z](?![A-Z]|
>  
>  DEFAULT_NAMES = ('verbose_name', 'db_table', 'ordering',
>   'unique_together', 'permissions', 'get_latest_by',
> - 'order_with_respect_to', 'app_label', 'db_tablespace')
> + 'order_with_respect_to', 'app_label', 'db_tablespace',
> +   

Re: Multiple primary keys

[Michael Radziej]

Hi Lars,

I found myself in a similar position, and I'm also coming from the database
side ... funny ;-)

I have attached a small patch that solved the problem for me and might be a
start for you, but be aware, it's more a crutch than a solution.

- this patch won't make it into the project, so you have to maintain it on
  your own

- it doesn't try to work for the admin or for newforms (but made be working
  for it), so I didn't have to deal with the admin URLs at all.

- it does not deal with creating databases or database introspection.

For a model with multiple primary keys, add an Meta class attribute
`has_composite_primary_key_key=True`. Here's an example model with 
multiple primary keys:

class Kundemail(UpdatelogMixin, models.Model):
kunde = models.ForeignKey(Kunde, db_column='kunde', primary_key = True)
dienst = DescriptorField(Descr, "dienst", db_column="dienst", primary_key = 
True)
person = models.ForeignKey(Person, db_column='person', primary_key = True)

class Meta:
db_table = 'kundemail'
has_composite_primary_key = True

So long,

Michael

-- 
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100
http://www.noris.de - The IT-Outsourcing Company
 
Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk - 
Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

>From nobody Mon Sep 17 00:00:00 2001
From: Michael Radziej <[EMAIL PROTECTED]>
Date: Mon Aug 13 16:03:06 2007 +0200
Subject: [PATCH] composite pkey

Refreshed patch composite-pkey.
(Base: da455ae19930af1b4513b37de8bd8e9f68ec6c3d)
(Last: 22c5ecf0407989824916f6b1676a4632c336a9d1)

---

 django/core/management.py   |9 -
 django/db/models/options.py |4 +++-
 2 files changed, 11 insertions(+), 2 deletions(-)

base 0f7580c29c7e992e9a071d3df62260e0609c2c68
last f7b6a55742bbf1ff867d841cdc17942fff357470
diff --git a/django/core/management.py b/django/core/management.py
index 882ff6de323a45a718c4d84b592da8a1ecc7357e..7f11101e69490faca4dcaac1b6acd29454a6ab0b 100644
--- a/django/core/management.py
+++ b/django/core/management.py
@@ -157,6 +157,7 @@ def _get_sql_model_create(model, known_models=set()):
 opts = model._meta
 final_output = []
 table_output = []
+composite_pkeys = []
 pending_references = {}
 for f in opts.fields:
 col_type = f.db_type()
@@ -172,7 +173,10 @@ def _get_sql_model_create(model, known_models=set()):
 if f.unique and (not f.primary_key or backend.allows_unique_and_pk):
 field_output.append(style.SQL_KEYWORD('UNIQUE'))
 if f.primary_key:
-field_output.append(style.SQL_KEYWORD('PRIMARY KEY'))
+if opts.has_composite_primary_key:
+composite_pkeys.append(f)
+else:
+field_output.append(style.SQL_KEYWORD('PRIMARY KEY'))
 if tablespace and backend.supports_tablespaces and (f.unique or f.primary_key) and backend.autoindexes_primary_keys:
 # We must specify the index tablespace inline, because we
 # won't be generating a CREATE INDEX statement for this field.
@@ -196,6 +200,9 @@ def _get_sql_model_create(model, known_models=set()):
 for field_constraints in opts.unique_together:
 table_output.append(style.SQL_KEYWORD('UNIQUE') + ' (%s)' % \
 ", ".join([backend.quote_name(style.SQL_FIELD(opts.get_field(f).column)) for f in field_constraints]))
+if opts.has_composite_primary_key:
+table_output.append(style.SQL_KEYWORD('PRIMARY KEY')+ ' (%s)' % \
+", ".join([backend.quote_name(style.SQL_FIELD(f.column)) for f in composite_pkeys]))
 
 full_statement = [style.SQL_KEYWORD('CREATE TABLE') + ' ' + style.SQL_TABLE(backend.quote_name(opts.db_table)) + ' (']
 for i, line in enumerate(table_output): # Combine and add commas.
diff --git a/django/db/models/options.py b/django/db/models/options.py
index 7cccb611cf354d5e9d5288a05f7c788ee6a4fa52..60e050b2ddd3a26a4941ba5fb1706338699137a7 100644
--- a/django/db/models/options.py
+++ b/django/db/models/options.py
@@ -15,7 +15,8 @@ get_verbose_name = lambda class_name: re.sub('(((?<=[a-z])[A-Z])|([A-Z](?![A-Z]|
 
 DEFAULT_NAMES = ('verbose_name', 'db_table', 'ordering',
  'unique_together', 'permissions', 'get_latest_by',
- 'order_with_respect_to', 'app_label', 'db_tablespace')
+ 'order_with_respect_to', 'app_label', 'db_tables

Re: Multiple primary keys

[Lars Stavholm]

Malcolm Tredinnick wrote:
> On Tue, 2007-08-14 at 06:51 +0200, Lars Stavholm wrote:
>> Malcolm Tredinnick wrote:
>>> On Tue, 2007-08-14 at 08:47 +0800, Russell Keith-Magee wrote:
>>> [...]
>>>> You will have more difficulty with the Admin application and generic
>>>> views. Both of these features rely upon the ability to install URLs
>>>> like:
>>>>
>>>> /path/to/object/42/ -> edit object 42
>>>>
>>>> This works fine if you have a single column primary key; however, if
>>>> you have multiple column primary keys, this isn't so easy to do. To
>>>> date, every proposed syntax for URL spaces supporting multiple primary
>>>> keys has either been syntactically ambiguous (e.g.,
>>>> /path/to/object/42,37 - which works unless the primary key has a comma
>>>> in it), or very inelegant (/path/to/object/42/37/ - which implies a
>>>> heirarchy where there isn't one). Any proposal for adding multiple
>>>> primary keys would need to address this very large issue.
>>> Remembering that primary keys are not just integers, so *any* string
>>> construct you come up with could also be the value of a single primary
>>> key. (e.g. "42/37/", in Russell's second example, could be a primary key
>>> value, too).
>> I see, not that simple.
>>
>> I guess the following idea has been discussed already then:
>>
>> Something like...
>>
>> /path/to/object/42,37
>>
>> ...where we use a setting like...
>>
>> PRIMARY_KEY_SEPARATOR = ','
>>
>> So, if the application needs to use another character to
>> separate the primary key fields, we could use, for example...
>>
>> /path/to/object/[EMAIL PROTECTED]
>>
>> PRIMARY_KEY_SEPARATOR = '@'
>>
>> ...maybe with a built in restriction of the allowed values
>> for  PRIMARY_KEY_SEPARATOR.
> 
> How will you know what your users will enter in the primary key? If it's

Well, all of the databases I've been looking at are sort
of professionally built, and don't really use arbitrary
strings for any primary key field. The usual case is a
combinations of integers, and in some cases a combination
of integers and simple/short strings, like unix usernames,
invoice number characters and integers mixed in a single
string field, and such. One could even assume that there's
no strange characters within the primary key field. I've
been working with RDBMSs for a good while, and I've never
seen any arbitrary-string-in-primary-key-field requirement,
no commas, no dots, no semicolons, nothing like that. It's
simply bad practice to have primary keys like that.

> something like a title or any other arbitrary field, aren't you out of
> luck? So then you end up looking at escaping mechanisms and it rapidly
> leads to ugly looking URLs.

I'm not really looking for the arbitrary string case, and
definitely not putting stuff like a title in the primary key.
It's a question of a primary key for an RDBMS, a couple of
best practice limitations fits in nicely, e.g. integers
(mostly) and short strings, like order number as a string,
invoice number as a string, stuff like that.

> Periodically, I wonder if it's worth implementing this anyway, just for
> fun, and then saying if you have multiple primary keys, you can't use
> those models in the admin. The mechanics are not that hard in most
> places (it's not entirely trivial, since we can't break existing code
> that uses the 'pk' attribute on models, etc). Current users would be no
> worse of. People using the new feature will do it with their eyes open
> and accepting the consequences of their decision (except therein lies
> the problem). I haven't gotten as far as pulling the trigger yet,
> though, since I always have other stuff to do.

Yes, well, I think it might be worth the effort. Imagine how many
legacy databases would benefit from a user interface built with
django, web or native. However, I do believe that the admin interface
should be an integral part of this, it's essential in getting your
application up and running quickly.

Just my 2c worth
/Lars


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Multiple primary keys

[Malcolm Tredinnick]

On Tue, 2007-08-14 at 06:51 +0200, Lars Stavholm wrote:
> Malcolm Tredinnick wrote:
> > On Tue, 2007-08-14 at 08:47 +0800, Russell Keith-Magee wrote:
> > [...]
> >> You will have more difficulty with the Admin application and generic
> >> views. Both of these features rely upon the ability to install URLs
> >> like:
> >>
> >> /path/to/object/42/ -> edit object 42
> >>
> >> This works fine if you have a single column primary key; however, if
> >> you have multiple column primary keys, this isn't so easy to do. To
> >> date, every proposed syntax for URL spaces supporting multiple primary
> >> keys has either been syntactically ambiguous (e.g.,
> >> /path/to/object/42,37 - which works unless the primary key has a comma
> >> in it), or very inelegant (/path/to/object/42/37/ - which implies a
> >> heirarchy where there isn't one). Any proposal for adding multiple
> >> primary keys would need to address this very large issue.
> > 
> > Remembering that primary keys are not just integers, so *any* string
> > construct you come up with could also be the value of a single primary
> > key. (e.g. "42/37/", in Russell's second example, could be a primary key
> > value, too).
> 
> I see, not that simple.
> 
> I guess the following idea has been discussed already then:
> 
> Something like...
> 
> /path/to/object/42,37
> 
> ...where we use a setting like...
> 
> PRIMARY_KEY_SEPARATOR = ','
> 
> So, if the application needs to use another character to
> separate the primary key fields, we could use, for example...
> 
> /path/to/object/[EMAIL PROTECTED]
> 
> PRIMARY_KEY_SEPARATOR = '@'
> 
> ...maybe with a built in restriction of the allowed values
> for  PRIMARY_KEY_SEPARATOR.

How will you know what your users will enter in the primary key? If it's
something like a title or any other arbitrary field, aren't you out of
luck? So then you end up looking at escaping mechanisms and it rapidly
leads to ugly looking URLs.

Periodically, I wonder if it's worth implementing this anyway, just for
fun, and then saying if you have multiple primary keys, you can't use
those models in the admin. The mechanics are not that hard in most
places (it's not entirely trivial, since we can't break existing code
that uses the 'pk' attribute on models, etc). Current users would be no
worse of. People using the new feature will do it with their eyes open
and accepting the consequences of their decision (except therein lies
the problem). I haven't gotten as far as pulling the trigger yet,
though, since I always have other stuff to do.

Regards,
Malcolm

-- 
The cost of feathers has risen; even down is up! 
http://www.pointy-stick.com/blog/


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Multiple primary keys

[Lars Stavholm]

Malcolm Tredinnick wrote:
> On Tue, 2007-08-14 at 08:47 +0800, Russell Keith-Magee wrote:
> [...]
>> You will have more difficulty with the Admin application and generic
>> views. Both of these features rely upon the ability to install URLs
>> like:
>>
>> /path/to/object/42/ -> edit object 42
>>
>> This works fine if you have a single column primary key; however, if
>> you have multiple column primary keys, this isn't so easy to do. To
>> date, every proposed syntax for URL spaces supporting multiple primary
>> keys has either been syntactically ambiguous (e.g.,
>> /path/to/object/42,37 - which works unless the primary key has a comma
>> in it), or very inelegant (/path/to/object/42/37/ - which implies a
>> heirarchy where there isn't one). Any proposal for adding multiple
>> primary keys would need to address this very large issue.
> 
> Remembering that primary keys are not just integers, so *any* string
> construct you come up with could also be the value of a single primary
> key. (e.g. "42/37/", in Russell's second example, could be a primary key
> value, too).

I see, not that simple.

I guess the following idea has been discussed already then:

Something like...

/path/to/object/42,37

...where we use a setting like...

PRIMARY_KEY_SEPARATOR = ','

So, if the application needs to use another character to
separate the primary key fields, we could use, for example...

/path/to/object/[EMAIL PROTECTED]

PRIMARY_KEY_SEPARATOR = '@'

...maybe with a built in restriction of the allowed values
for  PRIMARY_KEY_SEPARATOR.

> Our other big goal is not to break the existing single primary key case.

Well, if that's a goal, I'm afraid I'm out of luck:|

> Preferably no change to existing URLs.

I see.

My conclusion is that the multiple primary key fields is not
going to happen, which is a pity, since introspection then
is of limited use.

Thanks for your input
/Lars


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Multiple primary keys

[Malcolm Tredinnick]

On Tue, 2007-08-14 at 08:47 +0800, Russell Keith-Magee wrote:
[...]
> You will have more difficulty with the Admin application and generic
> views. Both of these features rely upon the ability to install URLs
> like:
> 
> /path/to/object/42/ -> edit object 42
> 
> This works fine if you have a single column primary key; however, if
> you have multiple column primary keys, this isn't so easy to do. To
> date, every proposed syntax for URL spaces supporting multiple primary
> keys has either been syntactically ambiguous (e.g.,
> /path/to/object/42,37 - which works unless the primary key has a comma
> in it), or very inelegant (/path/to/object/42/37/ - which implies a
> heirarchy where there isn't one). Any proposal for adding multiple
> primary keys would need to address this very large issue.

Remembering that primary keys are not just integers, so *any* string
construct you come up with could also be the value of a single primary
key. (e.g. "42/37/", in Russell's second example, could be a primary key
value, too).

Our other big goal is not to break the existing single primary key case.
Preferably no change to existing URLs.

Regards,
Malcolm

-- 
Plan to be spontaneous - tomorrow. 
http://www.pointy-stick.com/blog/


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Multiple primary keys

[Russell Keith-Magee]

On 8/14/07, Lars Stavholm <[EMAIL PROTECTED]> wrote:
>
> Hi all,
>
> first of all: django rocks! I'm a database application developer

Glad you like it! Welcome to the community.

> I know that this has been discussed on this list, but what I would
> like to know now is: is there any effort going into creating the
> "multiple fields in the primary key" feature at all? If so, is there
> anything I could do to help, short of trying to implement it myself,
> which I doubt that I'll be able to?
>
> Any input appreciated.

At present, there isn't any effort going on in this area. If you want
to contribute, this would be a very big contribution.

However, be warned - there is a reason we haven't addressed this issue.

On a model level, it shouldn't be too difficult to implement - allow
primary_key=True to be defined on multiple fields, and interpret those
fields appropriately when the table is created. You would also need to
modify the query syntax to ensure that queries over pk accept tuples
rather than just being a simple alias for the primary key field.

You will have more difficulty with the Admin application and generic
views. Both of these features rely upon the ability to install URLs
like:

/path/to/object/42/ -> edit object 42

This works fine if you have a single column primary key; however, if
you have multiple column primary keys, this isn't so easy to do. To
date, every proposed syntax for URL spaces supporting multiple primary
keys has either been syntactically ambiguous (e.g.,
/path/to/object/42,37 - which works unless the primary key has a comma
in it), or very inelegant (/path/to/object/42/37/ - which implies a
heirarchy where there isn't one). Any proposal for adding multiple
primary keys would need to address this very large issue.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Multiple primary keys

[Lars Stavholm]

Hi all,

first of all: django rocks! I'm a database application developer
and not a web developer. I'm not even fluent in python. Despite
that, the django framework has made it possible for me to develop
web based database applications with relative ease. And, I can
use the model and the database api for native applications using
WxPython. This is really great and this got to be the most productive
environment ever. This is what the 4GL languages tried to accomplish
back in the 90's, and they all failed miserably.

However, there's one significant piece I'm missing when introspecting
old database applications and trying to create new user interfaces
for them, and that's the lack of multiple fields in the primary key
for a table.

I know that this has been discussed on this list, but what I would
like to know now is: is there any effort going into creating the
"multiple fields in the primary key" feature at all? If so, is there
anything I could do to help, short of trying to implement it myself,
which I doubt that I'll be able to?

Any input appreciated.
/Lars


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users?hl=en
-~--~~~~--~~--~--~---

Re: Re: inspect and multiple primary keys

[Russell Keith-Magee]

On 10/19/06, flynnguy <[EMAIL PROTECTED]> wrote:
>
> Yes, but don't I still need to specify a primary key in django?

Yes you do, but you can nominate any field in your model as the
primary key - you don't have to use 'id'. If you add a
primary_key=True argument to the definition of any field, it will be
treated as the primary key.

The purpose of this approach is to create a Django definition of a
model that would produce an SQL table that functions the same (at a
query level) to the SQL table that you already have. To emit basic
searches, you don't need to know exactly which field is the primary
key - you only need to know the name and type of the available table
columns.

This approach isn't perfect. There are a few places it will fall down.
Anything relying upon the primary key for identification will fail -
for example making foreign key queries. However, basic queries and
model modifications should be possible.

If you're having difficulties, can you provide the SQL schema you are
trying to use, and the result of running manage.py inspectdb on that
schema?

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: inspect and multiple primary keys

[flynnguy]

Russell Keith-Magee wrote:
> However, as suggested in the ticket, you can work around the problem
> by hand writing the schema yourself (or, in your case, inheriting some
> schema from elsewhere), then writing a Django model that replicates
> everything in your schema _except_ the mutliple primary key, and use
> 'unique_together' as a constraint to produce behaviour similar to a
> multiple primary key.

Yes, but don't I still need to specify a primary key in django? The
real issue is that neither of these primary keys are unique alone, just
together. I'm trying to add a primary key called id (just for django)
but I keep getting a Multiple primary key defined error.

ie:
alter table recorded add primary key(id);
or
alter table recorded add primary key(id, chanid, starttime);

also I can't just add the id column because I need to make it
auto_increment which can only be done on a primary key field. Anyone
have any ideas?


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

Re: inspect and multiple primary keys

[Russell Keith-Magee]

On 10/19/06, flynnguy <[EMAIL PROTECTED]> wrote:
>
> In searching I found Ticket #373 which seems to discuss the issue but
> doesn't offer a workaround or anything. I'm trying to think of how I
> can make this work. I guess I could just write my own sql but I'd like
> the ability to use the admin console. Does anyone have any suggestions?

Django doesn't currently have support for multiple primary keys, and
as far as I know, nobody is really looking at the problem.

However, as suggested in the ticket, you can work around the problem
by hand writing the schema yourself (or, in your case, inheriting some
schema from elsewhere), then writing a Django model that replicates
everything in your schema _except_ the mutliple primary key, and use
'unique_together' as a constraint to produce behaviour similar to a
multiple primary key.

This approach isn't perfect, but it should get some of the admin
interface working, and should allow most queries to operate without
resorting to custom SQL all the time.

Yours,
Russ Magee %-)

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---

inspect and multiple primary keys

[flynnguy]

I'm trying to inspect my db for mythtv. I'm running into issues with
the inspect command because of the 0 date issue, not a problem, I'm
just creating the models I need by hand. The issue I am currently
running into is the recorded table has two primary keys (chanid and
starttime).

In searching I found Ticket #373 which seems to discuss the issue but
doesn't offer a workaround or anything. I'm trying to think of how I
can make this work. I guess I could just write my own sql but I'd like
the ability to use the admin console. Does anyone have any suggestions?


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/django-users
-~--~~~~--~~--~--~---