Re: Django models `EmailField` default is empty string - Not `None` (or Null) . Why ?

[Aymeric Augustin]

Hello,

https://docs.djangoproject.com/en/3.2/ref/models/fields/#django.db.models.Field.null
 

 should clarify the situation.

-- 
Aymeric.



> On 13 Jun 2021, at 13:17, Carlos Leite  wrote:
> 
> 
> Yesterday I realized that, Django email field default value is not "Null" 
> actually is an empty string ("")  - Although I'm not code often, I was 
> surprised.
> 
> I wrote some tests for a model where an  `emailfield` was supposed to be 
> `null=False`. 
> 
> But during the tests, it didn't raise an Exception (when persist on DB). Or 
> for a ModelForm `is_valid` in fact was True.
> 
> I did some (not a lot) research, and it seems the default value for an empty 
> value for EmailField is ""
> Isn't it counter productive? (at least for me, it was)
> I believe, the empty value,  is a special case for a Model Field 
> and I couldn't find any  information on docs. (I told I did SOME research) 
> I did check 
> https://docs.djangoproject.com/en/3.2/ref/models/fields/#emailfield 
> 
> 
> Please let me know my expectations make sense, I'll do my best for help, 
> if not, I know its not the place for "help", just tell me I'm wrong. 
> 
> Thanks everyone.
> 
> 
> Cadu Leite
> | Twitter 
> | @cadu_leite 
> 
> http://people.python.org.br/ 
> 
> -- 
> 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 view this discussion on the web visit 
> https://groups.google.com/d/msgid/django-developers/CAEM6-Q%2B1VHddFaXWNFgdd3fU%2B1BHOVo0U%3De-SOt2-ptFq24CcQ%40mail.gmail.com
>  
> .

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/BDFE41D4-0087-4EA3-970D-3F20D0C30502%40polytechnique.org.

Django models `EmailField` default is empty string - Not `None` (or Null) . Why ?

[Carlos Leite]

Yesterday I realized that, Django email field default value is not "Null"
actually is an empty string ("")  - Although I'm not code often, I was
surprised.

I wrote some tests for a model where an  `emailfield` was supposed to be
`null=False`.

But during the tests, it didn't raise an Exception (when persist on DB). Or
for a ModelForm `is_valid` in fact was True.

I did some (not a lot) research, and it seems the default value for an
empty value for EmailField is ""
Isn't it counter productive? (at least for me, it was)
I believe, the empty value,  is a special case for a Model Field
and I couldn't find any  information on docs. (I told I did SOME research)
I did check
https://docs.djangoproject.com/en/3.2/ref/models/fields/#emailfield

Please let me know my expectations make sense, I'll do my best for help,
if not, I know its not the place for "help", just tell me I'm wrong.

Thanks everyone.


Cadu Leite
| Twitter
| @cadu_leite 

http://people.python.org.br/

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAEM6-Q%2B1VHddFaXWNFgdd3fU%2B1BHOVo0U%3De-SOt2-ptFq24CcQ%40mail.gmail.com.

Re: Django Models

[Adam Johnson]

Hi!

I think you've found the wrong mailing list for this post. This mailing
list is for the development of Django itself, not for support using Django.
This means the discussions of bugs and features in Django itself, rather
than in your code using it. People on this list are unlikely to answer your
support query with their limited time and energy. Read more on the mailing
lists at https://www.djangoproject.com/community/

For support, please use the django-users mailing list, or IRC #django on
Freenode, or a site like Stack Overflow. There are people out there willing
to help on those channels, but they might not respond if you don't ask your
question well. Stack Overflow's question guide can help you frame it well:
https://stackoverflow.com/help/how-to-ask .

Also if you haven't read it, please take a look at Django's Code of
Conduct: https://www.djangoproject.com/conduct/ . These are our "ground
rules" for working well as a community, and will help you get the most out
of Django and our fantastic community.

As for your question - the Django official tutorial guides you through
creating some models with foreign keys, so should serve as a great starting
point for you: https://docs.djangoproject.com/en/2.2/intro/tutorial01/ .
Also see my blog post
https://adamj.eu/tech/2019/03/21/where-to-learn-django-in-2019/ for more
learning resources.

Thanks for your understanding,

Adam

On Fri, 9 Aug 2019 at 02:17, RAVVE MAALIE  wrote:

> Actually you can refer to one to many relation model.
>
> Its like one user has multiple address
> Or
> One adress has multiple users.
>
> In models file.
> You can make changes.
> Like
> For 1 user multiple address
> Eg:
> Class User(models.Model):
> User_name= models.Charfield()
> Class address(models.Model):
> Adre=model.ForeignKey(User, on_delete=models.CASCADE)
>
>
>
>
> On Fri, Aug 9, 2019, 02:36 göktürk sığırtmaç 
> wrote:
>
>> Hi, I'm developing app with django. I have users module. My database
>> schema users table and address table. Address table have foreign key from
>> users table. Now how can compose app architecture? Should i new module as
>> address and i should put address model etc. or Should i write address table
>> in users model? Does second choose violate single responsibility principle.
>>
>> --
>> 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 view this discussion on the web visit
>> https://groups.google.com/d/msgid/django-developers/91e6ab67-868b-4f83-a2da-6a04646a97b0%40googlegroups.com
>> 
>> .
>>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/CAAB4E736Xwbzfe-ypFxcsM2jhex-J%2BOUvqbsoYtr%2B01nm2NsxA%40mail.gmail.com
> 
> .
>


-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAMyDDM2zhRXHUzddTEKAzbuK8vmPUT17QU0xPy%3DdxCvjrUrCYw%40mail.gmail.com.

Re: Django Models

[RAVVE MAALIE]

Actually you can refer to one to many relation model.

Its like one user has multiple address
Or
One adress has multiple users.

In models file.
You can make changes.
Like
For 1 user multiple address
Eg:
Class User(models.Model):
User_name= models.Charfield()
Class address(models.Model):
Adre=model.ForeignKey(User, on_delete=models.CASCADE)




On Fri, Aug 9, 2019, 02:36 göktürk sığırtmaç  wrote:

> Hi, I'm developing app with django. I have users module. My database
> schema users table and address table. Address table have foreign key from
> users table. Now how can compose app architecture? Should i new module as
> address and i should put address model etc. or Should i write address table
> in users model? Does second choose violate single responsibility principle.
>
> --
> 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 view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/91e6ab67-868b-4f83-a2da-6a04646a97b0%40googlegroups.com
> 
> .
>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/CAAB4E736Xwbzfe-ypFxcsM2jhex-J%2BOUvqbsoYtr%2B01nm2NsxA%40mail.gmail.com.

Django Models

[göktürk sığırtmaç]

Hi, I'm developing app with django. I have users module. My database schema 
users table and address table. Address table have foreign key from users 
table. Now how can compose app architecture? Should i new module as address 
and i should put address model etc. or Should i write address table in 
users model? Does second choose violate single responsibility principle.

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/91e6ab67-868b-4f83-a2da-6a04646a97b0%40googlegroups.com.

Re: Extending Django models with Schevo

[Tim Allen]

Hi Etienne, like Tim G. said, you'll probably have better luck with the 
django-users mailing list. This group is for development discussion of core 
Django itself.

You may also want to reconsider using Schevo; I remember hearing about it 
long ago, but it doesn't appear that is has been actively developed in a 
decade, and only supports up to Python version 2.5, which has not been 
supported in years.

Good luck. Regards,

The other Tim

On Saturday, February 18, 2017 at 5:15:59 AM UTC-5, Etienne Robillard wrote:
>
> Hi Tim,
>
> I'm looking for technical comments about developing Django models classes 
> using the Schevo DBMS.
>
> http://www.isotopesoftware.ca/documentation/libschevo/
>
> I would like to use this like so:
>
> $ manage.py schevo test myapp
>
> $ manage.py schevo db-update myapp
>
> $ manage.py schevo shell 
>
> The "schevo" string is a command to access the Schevo API from the Django 
> management script.
>
> The Django model classes I need would provide a bridge to the Schevo 
> databases.
>
> Kind regards,
>
> E
>
>
> Le 2017-02-17 à 19:20, Tim Graham a écrit :
>
> Hi Etienne, I'm not sure exactly what type of response you're looking for 
> or if this is on-topic for the Django developers mailing list, which 
> pertains to the development of Django itself. django-users seems more 
> appropriate unless you're proposing some feature for Django.
>
> On Friday, February 17, 2017 at 3:57:42 PM UTC-5, Etienne Robillard wrote: 
>>
>> Hi, 
>>
>> I'm planning to extend django-hotsauce to support a generic "model" API. 
>> I would like to reuse the Django models API to support Schevo databases. 
>> Ideally, I would like to introspect into my reusable Django apps to 
>> discover configured features. Importing and exporting data from/to 
>> Schevo databases using JSON fixtures would also be a great addition. 
>>
>> Any ideas if Django 1.10 can be used for this? 
>>
>> Kind regards, 
>>
>> Etienne 
>>
>> -- 
>> Etienne Robillard 
>> tka...@yandex.com 
>> http://www.isotopesoftware.ca/ 
>>
>> -- 
> 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-develop...@googlegroups.com .
> To post to this group, send email to django-d...@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/f907064e-f4c4-4c73-aa31-0204b7ee1c12%40googlegroups.com
>  
> <https://groups.google.com/d/msgid/django-developers/f907064e-f4c4-4c73-aa31-0204b7ee1c12%40googlegroups.com?utm_medium=email_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
> -- 
> Etienne robillardtka...@yandex.com http://www.isotopesoftware.ca/
>
>

-- 
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/9edba0a4-b1e7-4509-b105-9e7404c5dc46%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending Django models with Schevo

[Etienne Robillard]

Hi Tim,

I'm looking for technical comments about developing Django models 
classes using the Schevo DBMS.


http://www.isotopesoftware.ca/documentation/libschevo/

I would like to use this like so:

$ manage.py schevo test myapp

$ manage.py schevo db-update myapp

$ manage.py schevo shell

The "schevo" string is a command to access the Schevo API from the 
Django management script.


The Django model classes I need would provide a bridge to the Schevo 
databases.


Kind regards,

E


Le 2017-02-17 à 19:20, Tim Graham a écrit :
Hi Etienne, I'm not sure exactly what type of response you're looking 
for or if this is on-topic for the Django developers mailing list, 
which pertains to the development of Django itself. django-users seems 
more appropriate unless you're proposing some feature for Django.


On Friday, February 17, 2017 at 3:57:42 PM UTC-5, Etienne Robillard 
wrote:


Hi,

I'm planning to extend django-hotsauce to support a generic
"model" API.
I would like to reuse the Django models API to support Schevo
databases.
Ideally, I would like to introspect into my reusable Django apps to
discover configured features. Importing and exporting data from/to
Schevo databases using JSON fixtures would also be a great addition.

Any ideas if Django 1.10 can be used for this?

Kind regards,

Etienne

-- 
Etienne Robillard

tka...@yandex.com 
http://www.isotopesoftware.ca/

--
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 
<mailto:django-developers+unsubscr...@googlegroups.com>.
To post to this group, send email to 
django-developers@googlegroups.com 
<mailto: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/f907064e-f4c4-4c73-aa31-0204b7ee1c12%40googlegroups.com 
<https://groups.google.com/d/msgid/django-developers/f907064e-f4c4-4c73-aa31-0204b7ee1c12%40googlegroups.com?utm_medium=email_source=footer>.

For more options, visit https://groups.google.com/d/optout.


--
Etienne Robillard
tkad...@yandex.com
http://www.isotopesoftware.ca/

--
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/3b1a19b2-5d06-8e45-e479-60ed5fb3bd72%40yandex.com.
For more options, visit https://groups.google.com/d/optout.

Re: Extending Django models with Schevo

[Tim Graham]

Hi Etienne, I'm not sure exactly what type of response you're looking for 
or if this is on-topic for the Django developers mailing list, which 
pertains to the development of Django itself. django-users seems more 
appropriate unless you're proposing some feature for Django.

On Friday, February 17, 2017 at 3:57:42 PM UTC-5, Etienne Robillard wrote:
>
> Hi, 
>
> I'm planning to extend django-hotsauce to support a generic "model" API. 
> I would like to reuse the Django models API to support Schevo databases. 
> Ideally, I would like to introspect into my reusable Django apps to 
> discover configured features. Importing and exporting data from/to 
> Schevo databases using JSON fixtures would also be a great addition. 
>
> Any ideas if Django 1.10 can be used for this? 
>
> Kind regards, 
>
> Etienne 
>
> -- 
> Etienne Robillard 
> tka...@yandex.com  
> http://www.isotopesoftware.ca/ 
>
>

-- 
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/f907064e-f4c4-4c73-aa31-0204b7ee1c12%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Extending Django models with Schevo

[Etienne Robillard]

Hi,

I'm planning to extend django-hotsauce to support a generic "model" API. 
I would like to reuse the Django models API to support Schevo databases. 
Ideally, I would like to introspect into my reusable Django apps to 
discover configured features. Importing and exporting data from/to 
Schevo databases using JSON fixtures would also be a great addition.


Any ideas if Django 1.10 can be used for this?

Kind regards,

Etienne

--
Etienne Robillard
tkad...@yandex.com
http://www.isotopesoftware.ca/

--
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/de1730ab-2c5e-310e-d7a8-38d0ca5f4e43%40yandex.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the primary key of Django models

[Tim Graham]

By the way, the django-developers mailing list is about the development of 
Django itself. Please keep usage questions limited to django-users. Thanks!

On Friday, February 5, 2016 at 6:10:04 PM UTC-5, Dheerendra Rathor wrote:
>
> Yes you can keep custom primary key. Pass `primary_key=True` in your model 
> and Django won't create a primary key for that model. 
>
> Here are relevant docs: 
> https://docs.djangoproject.com/en/1.9/ref/models/fields/#django.db.models.Field.primary_key
>
> On Fri, 5 Feb 2016 at 20:52 Uri Even-Chen <u...@speedy.net > 
> wrote:
>
>> To django-d...@googlegroups.com ,
>>
>> I'm a Django user and I'm working on converting Speedy Net from PHP to 
>> Django. I would like to know if it's possible in Django to change the 
>> primary key of Django models, such as User? I don't like the auto-increment 
>> default primary key, it doesn't make sense, and I want to use the primary 
>> key of users and pages also in urls. And therefore I decided that the id of 
>> users and pages, causes, groups and events on Speedy Net will be 15 
>> randomly generated digits. Users who already created accounts and pages on 
>> Speedy Net (with PHP) already have a 15-digits id, and I want to preserve 
>> this number when converting Speedy Net to Django. Is it possible? I don't 
>> want the id/primary key to be short (such as zuck's id on Facebook - 
>> https://www.facebook.com/messages/4) but 15-digits long.
>>
>> Thanks,
>> Uri.
>>
>> *Uri Even-Chen*   
>> [image: photo] Phone: +972-54-3995700
>> Email: u...@speedy.net 
>> Website: http://www.speedysoftware.com/uri/en/
>> <http://www.facebook.com/urievenchen>  
>> <http://plus.google.com/+urievenchen>  
>> <http://www.linkedin.com/in/urievenchen>  
>> <http://twitter.com/urievenchen>
>>
>>
>> -- Forwarded message --
>> From: Uri Even-Chen <u...@speedy.net >
>> Date: Thu, Feb 4, 2016 at 6:20 PM
>> Subject: ID for users of Speedy Net
>> To: django...@googlegroups.com 
>> Cc: speedy-mai...@googlegroups.com 
>>
>>
>> To django...@googlegroups.com ,
>>
>> I'm working on the next version of Speedy Net <http://en.speedy.net/>, 
>> which will be based on Django 1.9.2 and Python 3.5 / 3.4. You can see the 
>> specification of Speedy Net on 
>> https://github.com/urievenchen/speedy-net/tree/master/speedy_net/specifications
>>  (the 
>> file is System Requirements Specification - Speedy Net.txt). The old code 
>> is in PHP and can be found on 
>> https://www.assembla.com/spaces/speedynet/subversion/source (all the 
>> Speedy Net projects are free software and open source). According to my 
>> specification, each user will have a unique ID of 15 digits (a 
>> number between 100,000,000,000,000 and 999,999,999,999,999, randomly 
>> generated), which will be unique over the system (of users, pages, groups, 
>> causes and events). And each user will have a username, and pages, groups 
>> and causes may also have an optional username (it's called "username" also 
>> on Facebook).
>>
>> So my question is, can I make this random ID the primary key of the User 
>> model? I don't want users to have 2 ids - one for Django and one of Speedy 
>> Net, it doesn't make sense. I want the id to be the same and unique. I also 
>> want to have an Id model to prevent a page and a user (for example) to have 
>> the same ID. And a Username model to prevent them from having the same 
>> username. Is it possible to do it with Django 1.9.2?
>>
>> By the way, if you want to help me develop Speedy Net, Speedy Composer, 
>> Speedy Match or Speedy Mail, please let me know. If you want you can also 
>> join Speedy Net and grab yourself a username at Speedy Net. I'm also 
>> sending a copy of this message to speedy-mai...@googlegroups.com 
>> , the list of developers of the Speedy Net projects.
>>
>> I have another, off-topic question. Anyone knows how I can create a 
>> company in Switzerland, and how much does it cost? Any links to lawyers who 
>> can do it for me? I decided to host Speedy Net in Switzerland, because of 
>> the privacy laws there, and I prefer a Swiss company for the same reason 
>> (Israel is much less advanced in privacy than Europe and Switzerland). I'm 
>> a resident and citizen of Israel, with an option to become a Spanish 
>> citizen too. And I don't want to host private information of people in 
>> Israel.
>>
>> Thanks,
>> Uri.
>>
>> *Uri Even-Chen*  
>> [image: photo] Phone: +972-54-3995700
&g

Re: Changing the primary key of Django models

[Dheerendra Rathor]

Yes you can keep custom primary key. Pass `primary_key=True` in your model
and Django won't create a primary key for that model.

Here are relevant docs:
https://docs.djangoproject.com/en/1.9/ref/models/fields/#django.db.models.Field.primary_key

On Fri, 5 Feb 2016 at 20:52 Uri Even-Chen <u...@speedy.net> wrote:

> To django-developers@googlegroups.com,
>
> I'm a Django user and I'm working on converting Speedy Net from PHP to
> Django. I would like to know if it's possible in Django to change the
> primary key of Django models, such as User? I don't like the auto-increment
> default primary key, it doesn't make sense, and I want to use the primary
> key of users and pages also in urls. And therefore I decided that the id of
> users and pages, causes, groups and events on Speedy Net will be 15
> randomly generated digits. Users who already created accounts and pages on
> Speedy Net (with PHP) already have a 15-digits id, and I want to preserve
> this number when converting Speedy Net to Django. Is it possible? I don't
> want the id/primary key to be short (such as zuck's id on Facebook -
> https://www.facebook.com/messages/4) but 15-digits long.
>
> Thanks,
> Uri.
>
> *Uri Even-Chen*
> [image: photo] Phone: +972-54-3995700
> Email: u...@speedy.net
> Website: http://www.speedysoftware.com/uri/en/
> <http://www.facebook.com/urievenchen>
> <http://plus.google.com/+urievenchen>
> <http://www.linkedin.com/in/urievenchen>  <http://twitter.com/urievenchen>
>
>
> -- Forwarded message --
> From: Uri Even-Chen <u...@speedy.net>
> Date: Thu, Feb 4, 2016 at 6:20 PM
> Subject: ID for users of Speedy Net
> To: django-us...@googlegroups.com
> Cc: speedy-mail-softw...@googlegroups.com
>
>
> To django-us...@googlegroups.com,
>
> I'm working on the next version of Speedy Net <http://en.speedy.net/>,
> which will be based on Django 1.9.2 and Python 3.5 / 3.4. You can see the
> specification of Speedy Net on
> https://github.com/urievenchen/speedy-net/tree/master/speedy_net/specifications
>  (the
> file is System Requirements Specification - Speedy Net.txt). The old code
> is in PHP and can be found on
> https://www.assembla.com/spaces/speedynet/subversion/source (all the
> Speedy Net projects are free software and open source). According to my
> specification, each user will have a unique ID of 15 digits (a
> number between 100,000,000,000,000 and 999,999,999,999,999, randomly
> generated), which will be unique over the system (of users, pages, groups,
> causes and events). And each user will have a username, and pages, groups
> and causes may also have an optional username (it's called "username" also
> on Facebook).
>
> So my question is, can I make this random ID the primary key of the User
> model? I don't want users to have 2 ids - one for Django and one of Speedy
> Net, it doesn't make sense. I want the id to be the same and unique. I also
> want to have an Id model to prevent a page and a user (for example) to have
> the same ID. And a Username model to prevent them from having the same
> username. Is it possible to do it with Django 1.9.2?
>
> By the way, if you want to help me develop Speedy Net, Speedy Composer,
> Speedy Match or Speedy Mail, please let me know. If you want you can also
> join Speedy Net and grab yourself a username at Speedy Net. I'm also
> sending a copy of this message to speedy-mail-softw...@googlegroups.com,
> the list of developers of the Speedy Net projects.
>
> I have another, off-topic question. Anyone knows how I can create a
> company in Switzerland, and how much does it cost? Any links to lawyers who
> can do it for me? I decided to host Speedy Net in Switzerland, because of
> the privacy laws there, and I prefer a Swiss company for the same reason
> (Israel is much less advanced in privacy than Europe and Switzerland). I'm
> a resident and citizen of Israel, with an option to become a Spanish
> citizen too. And I don't want to host private information of people in
> Israel.
>
> Thanks,
> Uri.
>
> *Uri Even-Chen*
> [image: photo] Phone: +972-54-3995700 <+972-54-3995700>
> Email: u...@speedy.net <u...@speedy.net>
> Website: http://www.speedysoftware.com/uri/en/
> <http://www.speedysoftware.com/uri/en/>
> <http://www.facebook.com/urievenchen>
> <http://plus.google.com/+urievenchen>
> <http://www.linkedin.com/in/urievenchen>  <http://twitter.com/urievenchen>
>
> --
> 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-develope

Changing the primary key of Django models

[Uri Even-Chen]

To django-developers@googlegroups.com,

I'm a Django user and I'm working on converting Speedy Net from PHP to
Django. I would like to know if it's possible in Django to change the
primary key of Django models, such as User? I don't like the auto-increment
default primary key, it doesn't make sense, and I want to use the primary
key of users and pages also in urls. And therefore I decided that the id of
users and pages, causes, groups and events on Speedy Net will be 15
randomly generated digits. Users who already created accounts and pages on
Speedy Net (with PHP) already have a 15-digits id, and I want to preserve
this number when converting Speedy Net to Django. Is it possible? I don't
want the id/primary key to be short (such as zuck's id on Facebook -
https://www.facebook.com/messages/4) but 15-digits long.

Thanks,
Uri.

*Uri Even-Chen*
[image: photo] Phone: +972-54-3995700
Email: u...@speedy.net
Website: http://www.speedysoftware.com/uri/en/
<http://www.facebook.com/urievenchen>  <http://plus.google.com/+urievenchen>
  <http://www.linkedin.com/in/urievenchen>  <http://twitter.com/urievenchen>


-- Forwarded message --
From: Uri Even-Chen <u...@speedy.net>
Date: Thu, Feb 4, 2016 at 6:20 PM
Subject: ID for users of Speedy Net
To: django-us...@googlegroups.com
Cc: speedy-mail-softw...@googlegroups.com


To django-us...@googlegroups.com,

I'm working on the next version of Speedy Net <http://en.speedy.net/>,
which will be based on Django 1.9.2 and Python 3.5 / 3.4. You can see the
specification of Speedy Net on
https://github.com/urievenchen/speedy-net/tree/master/speedy_net/specifications
(the
file is System Requirements Specification - Speedy Net.txt). The old code
is in PHP and can be found on
https://www.assembla.com/spaces/speedynet/subversion/source (all the Speedy
Net projects are free software and open source). According to my
specification, each user will have a unique ID of 15 digits (a
number between 100,000,000,000,000 and 999,999,999,999,999, randomly
generated), which will be unique over the system (of users, pages, groups,
causes and events). And each user will have a username, and pages, groups
and causes may also have an optional username (it's called "username" also
on Facebook).

So my question is, can I make this random ID the primary key of the User
model? I don't want users to have 2 ids - one for Django and one of Speedy
Net, it doesn't make sense. I want the id to be the same and unique. I also
want to have an Id model to prevent a page and a user (for example) to have
the same ID. And a Username model to prevent them from having the same
username. Is it possible to do it with Django 1.9.2?

By the way, if you want to help me develop Speedy Net, Speedy Composer,
Speedy Match or Speedy Mail, please let me know. If you want you can also
join Speedy Net and grab yourself a username at Speedy Net. I'm also
sending a copy of this message to speedy-mail-softw...@googlegroups.com,
the list of developers of the Speedy Net projects.

I have another, off-topic question. Anyone knows how I can create a company
in Switzerland, and how much does it cost? Any links to lawyers who can do
it for me? I decided to host Speedy Net in Switzerland, because of the
privacy laws there, and I prefer a Swiss company for the same reason
(Israel is much less advanced in privacy than Europe and Switzerland). I'm
a resident and citizen of Israel, with an option to become a Spanish
citizen too. And I don't want to host private information of people in
Israel.

Thanks,
Uri.

*Uri Even-Chen*
[image: photo] Phone: +972-54-3995700 <+972-54-3995700>
Email: u...@speedy.net <u...@speedy.net>
Website: http://www.speedysoftware.com/uri/en/
<http://www.speedysoftware.com/uri/en/>
<http://www.facebook.com/urievenchen>  <http://plus.google.com/+urievenchen>
  <http://www.linkedin.com/in/urievenchen>  <http://twitter.com/urievenchen>

-- 
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/CAMQ2MsGMip-WreMzjrpZFxJUB3edJz9RQoiMLoo5tEwjU-7pfw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: About: Feature request: Comments in Django models saved to database schema

[Anssi Kääriäinen]

On 26 heinä, 18:55, Andrei Antoukh  wrote:
> 2012/7/24 Anssi Kääriäinen 
>
> > On 22 heinä, 23:01, Andrei Antoukh  wrote:
> > > Hello!
>
> Hello!
>
>
>
>
>
>
>
>
>
>
>
> > > I started working on what had been proposed. In the commithttps://
> > github.com/niwibe/django/commit/af887029integeintege614ca53d8...<
> >https://github.com/niwibe/django/commit/af887029614ca53d8bdab23f0a40e...>
> > > is
> > > the initial implementation. It is based on the Anssi idea.
>
> > > I have some doubts about how to make things better. The proposed method
> > > should return a list of sql statements:
> > > ["COMMENT ON TABLE fooapp_sampletable IS 'Foo comment';"]
>
> > > or a list of tuples with sql statements with possible arguments:
>
> > > [("COMMENT ON TABLE fooapp_sampletable IS %s", ["Foo comment"])]
>
> > > Currently, the initial implementation, is a list of tuples, but I'm
> > > wondering if the best option. I think that this is not usabe for commands
> > > such as sqlall because the returned sql is not complete, if only partial,
> > > failing to place them arguments.
>
> > I do think the sqlall output should be usable as is. That is, the
> > return value should be list of strings. This might mean that one has
> > to create the SQL in a way that is susceptible to SQL injection
> > attacks, but I don't see that as a problem. The post_sync method's SQL
> > can't be ran or controlled by users, so there is no attack vector.
>
> OK!
>
>
>
> > I have a couple of questions:
> >   1) How does this work in model inheritance situations? If the base
> > model defines post_sync_sql(), wouldn't that be called again for the
> > child models? Maybe it is possible to run the method only if it is
> > defined in the current class directly. This should be possible by
> > inspecting the model's __dict__ for the method instead of using
> > hasattr.
>
> Good observation!
>
> >   2) What is the order in which the post_sync_sql methods are called?
> > This could be important for some use cases (one view depends on
> > another view for example). I guess the order is app for app in
> > INSTALLED_APPS, models in the order they are found from app's
> > models.py? The order should be tested and documented.
>
> I'll think about it. Currently uses the same order as syncdb, even if not
> the most appropriate for this.
> We could think of a way to define the order of execution by the user.
>
> I created the asociated ticket for this 
> feature:https://code.djangoproject.com/tidcket/18672
>
> Andrey.

Before proceeding too far in the morel pre/post sync hooks, lets see
if the other current thread about a similar issues yields a better
API. The other thread is about raw SQL on pre/post sync, and while it
isn't dealing with the exact same issue as this thread, there is a lot
of overlap. See 
http://groups.google.com/group/django-developers/browse_thread/thread/c4dd1a333ae60356

 - Anssi

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

Re: About: Feature request: Comments in Django models saved to database schema

[Andrei Antoukh]

2012/7/24 Anssi Kääriäinen 

> On 22 heinä, 23:01, Andrei Antoukh  wrote:
> > Hello!
>

Hello!


> >
> > I started working on what had been proposed. In the commithttps://
> github.com/niwibe/django/commit/af887029integeintege614ca53d8...<
> https://github.com/niwibe/django/commit/af887029614ca53d8bdab23f0a40e...>
> > is
> > the initial implementation. It is based on the Anssi idea.
> >
> > I have some doubts about how to make things better. The proposed method
> > should return a list of sql statements:
> > ["COMMENT ON TABLE fooapp_sampletable IS 'Foo comment';"]
> >
> > or a list of tuples with sql statements with possible arguments:
> >
> > [("COMMENT ON TABLE fooapp_sampletable IS %s", ["Foo comment"])]
> >
> > Currently, the initial implementation, is a list of tuples, but I'm
> > wondering if the best option. I think that this is not usabe for commands
> > such as sqlall because the returned sql is not complete, if only partial,
> > failing to place them arguments.
>
> I do think the sqlall output should be usable as is. That is, the
> return value should be list of strings. This might mean that one has
> to create the SQL in a way that is susceptible to SQL injection
> attacks, but I don't see that as a problem. The post_sync method's SQL
> can't be ran or controlled by users, so there is no attack vector.
>

OK!



>
> I have a couple of questions:
>   1) How does this work in model inheritance situations? If the base
> model defines post_sync_sql(), wouldn't that be called again for the
> child models? Maybe it is possible to run the method only if it is
> defined in the current class directly. This should be possible by
> inspecting the model's __dict__ for the method instead of using
> hasattr.
>

Good observation!


>   2) What is the order in which the post_sync_sql methods are called?
> This could be important for some use cases (one view depends on
> another view for example). I guess the order is app for app in
> INSTALLED_APPS, models in the order they are found from app's
> models.py? The order should be tested and documented.
>

I'll think about it. Currently uses the same order as syncdb, even if not
the most appropriate for this.
We could think of a way to define the order of execution by the user.

I created the asociated ticket for this feature:
https://code.djangoproject.com/tidcket/18672

Andrey.



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


-- 
Andrei Antoukh - 
http://www.niwi.be/page/about/
http://www.kaleidos.net/A5694F/

"Linux is for people who hate Windows, BSD is for people who love UNIX"
"Social Engineer -> Because there is no patch for human stupidity"

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

Re: About: Feature request: Comments in Django models saved to database schema

[Anssi Kääriäinen]

On 22 heinä, 23:01, Andrei Antoukh  wrote:
> Hello!
>
> I started working on what had been proposed. In the 
> commithttps://github.com/niwibe/django/commit/af887029integeintege614ca53d8...
> is
> the initial implementation. It is based on the Anssi idea.
>
> I have some doubts about how to make things better. The proposed method
> should return a list of sql statements:
> ["COMMENT ON TABLE fooapp_sampletable IS 'Foo comment';"]
>
> or a list of tuples with sql statements with possible arguments:
>
> [("COMMENT ON TABLE fooapp_sampletable IS %s", ["Foo comment"])]
>
> Currently, the initial implementation, is a list of tuples, but I'm
> wondering if the best option. I think that this is not usabe for commands
> such as sqlall because the returned sql is not complete, if only partial,
> failing to place them arguments.

I do think the sqlall output should be usable as is. That is, the
return value should be list of strings. This might mean that one has
to create the SQL in a way that is susceptible to SQL injection
attacks, but I don't see that as a problem. The post_sync method's SQL
can't be ran or controlled by users, so there is no attack vector.

I have a couple of questions:
  1) How does this work in model inheritance situations? If the base
model defines post_sync_sql(), wouldn't that be called again for the
child models? Maybe it is possible to run the method only if it is
defined in the current class directly. This should be possible by
inspecting the model's __dict__ for the method instead of using
hasattr.

  2) What is the order in which the post_sync_sql methods are called?
This could be important for some use cases (one view depends on
another view for example). I guess the order is app for app in
INSTALLED_APPS, models in the order they are found from app's
models.py? The order should be tested and documented.

 - Anssi

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

Re: About: Feature request: Comments in Django models saved to database schema

[Andrei Antoukh]

Hello!

I started working on what had been proposed. In the commit
https://github.com/niwibe/django/commit/af887029integeintege614ca53d8bdab23f0a40ee7420b9bc20
is
the initial implementation. It is based on the Anssi idea.

I have some doubts about how to make things better. The proposed method
should return a list of sql statements:
["COMMENT ON TABLE fooapp_sampletable IS 'Foo comment';"]

or a list of tuples with sql statements with possible arguments:

[("COMMENT ON TABLE fooapp_sampletable IS %s", ["Foo comment"])]

Currently, the initial implementation, is a list of tuples, but I'm
wondering if the best option. I think that this is not usabe for commands
such as sqlall because the returned sql is not complete, if only partial,
failing to place them arguments.

Thank you very much!
Andrey Antukh



2012/7/9 Andrei Antoukh 

> 2012/7/9 Anssi Kääriäinen 
>
>> On 7 heinä, 22:25, Andrei Antoukh  wrote:
>> > Hello!
>> >
>> > I am writing about the issues:
>> https://code.djangoproject.com/ticket/13867https://code.djangoproject.com/ticket/18468
>> >
>> > I am not the author of these issues, but I think this feature is
>> > interesting to have in the ORM.
>> > I agree that we should not do things just because we can make!
>> >
>> > In the source code often put comments to clarify things. These comments
>> for
>> > the same project
>> > developer or someone who looks at the source code are often useful to
>> know
>> > how
>> > something works or understand something that is not entirely clear.
>> >
>> > In SQL's absolutely the same case. Sometimes you need to make comments
>> on
>> > both tables to clarify
>> > the purpose and functionality, and in columns. All assume that if you
>> want
>> > to understand something,
>> >  look at the source code, but this may not always be so.
>> >
>> > Right now, the behavior to make comments can be emulated using sql
>> > fixtures. And it has these drawbacks:
>> >
>> > * Is not portable between different database backends, 3 files need to
>> > write redundant for this in mysql,
>> > postgresql and sqlite (sqlite does not natively support comments, but
>> you
>> > can emulate sqlhttp://
>> stackoverflow.com/questions/7426205/sqlitecomments
>> > -adding-comments-to-tables-and-columns )
>> >
>> > * It is more tedious to write SQL statements and you end up not making
>> the
>> > comments.
>> >
>> > Is a low priority feature (obviously) but I think it's something that
>> could
>> > facilitate the ORM.
>> >
>> > My first proposal is:
>> > Comments to model tables (for mysql, postgresql and sqlite3) as the
>> first
>> > patch.
>> > Without any kind of magic by django, a simple attribute "comment" on
>> object
>> > "Meta".
>> >
>> > My initial proposal for postgresql implementation:
>> https://github.com/niwibe/django/tree/issue_18468
>>
>> I am not sure this is something we want to support. To me a generic
>> "get_post_sync_sql(connection)" is a better approach. In addition to
>> comments you could add indexes, constraints and so on in the hook. It
>> should be called even for non-managed tables. That way you could use
>> views using the hook. Trivial example:
>>
>> class UserPostCount(models.Model):
>> user = models.OneToOneKey(User, primary_key=True,
>> db_column="user_id", on_delete=models.DO_NOTHING,
>> related_name='post_count')
>> post_count = models.IntegerField()
>>
>> class Meta:
>> db_table = 'user_post_count_view'
>> managed = False
>>
>> def get_post_sync_sql(connection):
>> if connection.vendor != 'postgresql':
>> raise NotImplementedError
>> return [
>> """
>> CREATE OR REPLACE VIEW user_post_count_view AS (
>> SELECT user.id AS user_id, count(*) AS post_count
>>   FROM user
>>   JOIN user_posts ON user.id = user_posts.user_id
>> );""",
>> """
>> COMMENT ON VIEW user_post_count_view IS 'A trivial view returning
>> post count for users.';
>> """]
>>
>> There could also be a get_post_flush_sql(connection) hook.
>>
>> It seems best if the hooks are called in a second pass - that is, the
>> whole schema is already installed into the DB before running any of
>> the post_sync SQL.
>>
>> Why not use the initial SQL files we already have? They are ran every
>> time after flush - which means they are useless for defining views for
>> example - and at least I like to keep the SQL together with model
>> definition. In addition (IIRC) there are some problems with backends
>> which do not support executing multiple statements in one go. Still,
>> one can do logic in the hook, while the initial SQL files are flat
>> files.
>>
>>  - Anssi
>>
>>
> Hi Anssi!
>
> I had submitted a proposal very simplistic. But your idea seems great! In
> fact I love it! And I would solve much more. As you've said: indexes,
> constrains, etc..
> I will present a 

Re: About: Feature request: Comments in Django models saved to database schema

[Andrei Antoukh]

2012/7/9 Anssi Kääriäinen 

> On 7 heinä, 22:25, Andrei Antoukh  wrote:
> > Hello!
> >
> > I am writing about the issues:
> https://code.djangoproject.com/ticket/13867https://code.djangoproject.com/ticket/18468
> >
> > I am not the author of these issues, but I think this feature is
> > interesting to have in the ORM.
> > I agree that we should not do things just because we can make!
> >
> > In the source code often put comments to clarify things. These comments
> for
> > the same project
> > developer or someone who looks at the source code are often useful to
> know
> > how
> > something works or understand something that is not entirely clear.
> >
> > In SQL's absolutely the same case. Sometimes you need to make comments on
> > both tables to clarify
> > the purpose and functionality, and in columns. All assume that if you
> want
> > to understand something,
> >  look at the source code, but this may not always be so.
> >
> > Right now, the behavior to make comments can be emulated using sql
> > fixtures. And it has these drawbacks:
> >
> > * Is not portable between different database backends, 3 files need to
> > write redundant for this in mysql,
> > postgresql and sqlite (sqlite does not natively support comments, but you
> > can emulate sqlhttp://stackoverflow.com/questions/7426205/sqlitecomments
> > -adding-comments-to-tables-and-columns )
> >
> > * It is more tedious to write SQL statements and you end up not making
> the
> > comments.
> >
> > Is a low priority feature (obviously) but I think it's something that
> could
> > facilitate the ORM.
> >
> > My first proposal is:
> > Comments to model tables (for mysql, postgresql and sqlite3) as the first
> > patch.
> > Without any kind of magic by django, a simple attribute "comment" on
> object
> > "Meta".
> >
> > My initial proposal for postgresql implementation:
> https://github.com/niwibe/django/tree/issue_18468
>
> I am not sure this is something we want to support. To me a generic
> "get_post_sync_sql(connection)" is a better approach. In addition to
> comments you could add indexes, constraints and so on in the hook. It
> should be called even for non-managed tables. That way you could use
> views using the hook. Trivial example:
>
> class UserPostCount(models.Model):
> user = models.OneToOneKey(User, primary_key=True,
> db_column="user_id", on_delete=models.DO_NOTHING,
> related_name='post_count')
> post_count = models.IntegerField()
>
> class Meta:
> db_table = 'user_post_count_view'
> managed = False
>
> def get_post_sync_sql(connection):
> if connection.vendor != 'postgresql':
> raise NotImplementedError
> return [
> """
> CREATE OR REPLACE VIEW user_post_count_view AS (
> SELECT user.id AS user_id, count(*) AS post_count
>   FROM user
>   JOIN user_posts ON user.id = user_posts.user_id
> );""",
> """
> COMMENT ON VIEW user_post_count_view IS 'A trivial view returning
> post count for users.';
> """]
>
> There could also be a get_post_flush_sql(connection) hook.
>
> It seems best if the hooks are called in a second pass - that is, the
> whole schema is already installed into the DB before running any of
> the post_sync SQL.
>
> Why not use the initial SQL files we already have? They are ran every
> time after flush - which means they are useless for defining views for
> example - and at least I like to keep the SQL together with model
> definition. In addition (IIRC) there are some problems with backends
> which do not support executing multiple statements in one go. Still,
> one can do logic in the hook, while the initial SQL files are flat
> files.
>
>  - Anssi
>
>
Hi Anssi!

I had submitted a proposal very simplistic. But your idea seems great! In
fact I love it! And I would solve much more. As you've said: indexes,
constrains, etc..
I will present a proposal for implementation with this in mind.

Andrei Antoukh

-- 
Andrei Antoukh - 
http://www.niwi.be/page/about/
http://www.kaleidos.net/A5 --
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
694F/ 

"Linux is for people who hate Windows, BSD is for people who love UNIX"
"Social Engineer -> Because there is no patch for human stupidity"

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to 
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at 

Re: About: Feature request: Comments in Django models saved to database schema

[Anssi Kääriäinen]

On 7 heinä, 22:25, Andrei Antoukh  wrote:
> Hello!
>
> I am writing about the 
> issues:https://code.djangoproject.com/ticket/13867https://code.djangoproject.com/ticket/18468
>
> I am not the author of these issues, but I think this feature is
> interesting to have in the ORM.
> I agree that we should not do things just because we can make!
>
> In the source code often put comments to clarify things. These comments for
> the same project
> developer or someone who looks at the source code are often useful to know
> how
> something works or understand something that is not entirely clear.
>
> In SQL's absolutely the same case. Sometimes you need to make comments on
> both tables to clarify
> the purpose and functionality, and in columns. All assume that if you want
> to understand something,
>  look at the source code, but this may not always be so.
>
> Right now, the behavior to make comments can be emulated using sql
> fixtures. And it has these drawbacks:
>
> * Is not portable between different database backends, 3 files need to
> write redundant for this in mysql,
> postgresql and sqlite (sqlite does not natively support comments, but you
> can emulate sqlhttp://stackoverflow.com/questions/7426205/sqlitecomments
> -adding-comments-to-tables-and-columns )
>
> * It is more tedious to write SQL statements and you end up not making the
> comments.
>
> Is a low priority feature (obviously) but I think it's something that could
> facilitate the ORM.
>
> My first proposal is:
> Comments to model tables (for mysql, postgresql and sqlite3) as the first
> patch.
> Without any kind of magic by django, a simple attribute "comment" on object
> "Meta".
>
> My initial proposal for postgresql 
> implementation:https://github.com/niwibe/django/tree/issue_18468

I am not sure this is something we want to support. To me a generic
"get_post_sync_sql(connection)" is a better approach. In addition to
comments you could add indexes, constraints and so on in the hook. It
should be called even for non-managed tables. That way you could use
views using the hook. Trivial example:

class UserPostCount(models.Model):
user = models.OneToOneKey(User, primary_key=True,
db_column="user_id", on_delete=models.DO_NOTHING,
related_name='post_count')
post_count = models.IntegerField()

class Meta:
db_table = 'user_post_count_view'
managed = False

def get_post_sync_sql(connection):
if connection.vendor != 'postgresql':
raise NotImplementedError
return [
"""
CREATE OR REPLACE VIEW user_post_count_view AS (
SELECT user.id AS user_id, count(*) AS post_count
  FROM user
  JOIN user_posts ON user.id = user_posts.user_id
);""",
"""
COMMENT ON VIEW user_post_count_view IS 'A trivial view returning
post count for users.';
"""]

There could also be a get_post_flush_sql(connection) hook.

It seems best if the hooks are called in a second pass - that is, the
whole schema is already installed into the DB before running any of
the post_sync SQL.

Why not use the initial SQL files we already have? They are ran every
time after flush - which means they are useless for defining views for
example - and at least I like to keep the SQL together with model
definition. In addition (IIRC) there are some problems with backends
which do not support executing multiple statements in one go. Still,
one can do logic in the hook, while the initial SQL files are flat
files.

 - Anssi

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

About: Feature request: Comments in Django models saved to database schema

[Andrei Antoukh]

Hello!

I am writing about the issues:
https://code.djangoproject.com/ticket/13867
https://code.djangoproject.com/ticket/18468

I am not the author of these issues, but I think this feature is
interesting to have in the ORM.
I agree that we should not do things just because we can make!

In the source code often put comments to clarify things. These comments for
the same project
developer or someone who looks at the source code are often useful to know
how
something works or understand something that is not entirely clear.

In SQL's absolutely the same case. Sometimes you need to make comments on
both tables to clarify
the purpose and functionality, and in columns. All assume that if you want
to understand something,
 look at the source code, but this may not always be so.

Right now, the behavior to make comments can be emulated using sql
fixtures. And it has these drawbacks:

* Is not portable between different database backends, 3 files need to
write redundant for this in mysql,
postgresql and sqlite (sqlite does not natively support comments, but you
can emulate sql
http://stackoverflow.com/questions/7426205/sqlite comments
-adding-comments-to-tables-and-columns )

* It is more tedious to write SQL statements and you end up not making the
comments.

Is a low priority feature (obviously) but I think it's something that could
facilitate the ORM.

My first proposal is:
Comments to model tables (for mysql, postgresql and sqlite3) as the first
patch.
Without any kind of magic by django, a simple attribute "comment" on object
"Meta".

My initial proposal for postgresql implementation:
https://github.com/niwibe/django/tree/issue_18468

Andrei Antoukh

PD: sorry for my poor inglish

-- 
Andrei Antoukh - 
http://www.niwi.be/page/about/
http://www.kaleidos.net/A5694F/

"Linux is for people who hate Windows, BSD is for people who love UNIX"
"Social Engineer -> Because there is no patch for human stupidity"

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

Re: Django models and different types

[Michael da Silva Pereira]

Apologies got the groups confused.

-- Mike

-- 

*
*
*Tradepage, now part of the Cloud Group, is an Authorised Google Apps for 
Business Reseller.  For only R450 per user per year, get Business Email, 
Calendars, Documents, syncing with mobile devices and much more. Find out 
more: http://www.tradepage.co.za/google-apps-for-business*


This email and all contents are subject to the following disclaimer:
http://www.tradepage.co.za/disclaimer

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

Re: Django models and different types

[Karen Tracey]

Please ask questions about using Django on django-users. The topic of this
list is the development of Django itself.

Karen

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

Django models and different types

[Michael da Silva Pereira]

Hi,

Looking for some ideas around a type / conversion matching issue I'm having
with a big django model.
The model has tons of variables, and all being of different types (int,
nullbool, date, datetime, string).

I'm trying to pass data from a different database into the django model,
but the other DB passes the info to me as string.

I don't really want to do type conversions for each and every field, there
are around 180 odd. Is there not some sort of function that be used to
automatically for the conversion?

Any ideas?

-- Mike

-- 

*
*
*Tradepage, now part of the Cloud Group, is an Authorised Google Apps for 
Business Reseller.  For only R450 per user per year, get Business Email, 
Calendars, Documents, syncing with mobile devices and much more. Find out 
more: http://www.tradepage.co.za/google-apps-for-business*


This email and all contents are subject to the following disclaimer:
http://www.tradepage.co.za/disclaimer

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

Re: Django models should not contain 'evaluate' field/method since Django 1.1

[Łukasz Korzybski]

Sure,

The ticket: http://code.djangoproject.com/ticket/13640#preview

Greetings,
Lukasz

On May 25, 2:49 pm, Jacob Kaplan-Moss  wrote:
> On Tue, May 25, 2010 at 12:06 PM, naos  wrote:
> > I was migrating some django project recently from django 1.0.4 to 1.2.
> > In Django 1.2/1.1 I found that if model have 'evaluate' attribute then
> > one will get exception in admin edit page for that model if the page
> > contains inline forms with related models:
>
> [snip]
>
> This is a bug and should be fixed by fixing the hasattr() check. Can
> you open a ticket, please?
>
> Jacob

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

Re: Django models should not contain 'evaluate' field/method since Django 1.1

[Jacob Kaplan-Moss]

On Tue, May 25, 2010 at 12:06 PM, naos  wrote:
> I was migrating some django project recently from django 1.0.4 to 1.2.
> In Django 1.2/1.1 I found that if model have 'evaluate' attribute then
> one will get exception in admin edit page for that model if the page
> contains inline forms with related models:

[snip]

This is a bug and should be fixed by fixing the hasattr() check. Can
you open a ticket, please?

Jacob

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

Django models should not contain 'evaluate' field/method since Django 1.1

[naos]

Hi,

I was migrating some django project recently from django 1.0.4 to 1.2.
In Django 1.2/1.1 I found that if model have 'evaluate' attribute then
one will get exception in admin edit page for that model if the page
contains inline forms with related models:

Exception Value:  'Shipper' object has no attribute 'prepare'
Exception Location: .../django/db/models/sql/expressions.py in
__init__, line 12

It is caused by the fact that add_filter function in django/db/models/
sql/query.py does such a check:

...
1005.  elif hasattr(value, 'evaluate'):
1006.  # If value is a query expression, evaluate it
1007.  value = SQLEvaluator(value, self) ...
1008.  having_clause = value.contains_aggregate
...

The problem is that "value" in this case is Shipper model which in
have "evaluate" method so it is recognized as query expression here.

I share about this cause I thought that maybe it is worth noting in
documentation, or this check should be changed somehow?

Greetings,

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

Re: Fully Polymorphic Django Models: a simple implementation

[hejsan]

This is the best news I've heard for a long time!

This was also my biggest disappointment with Django. This bit me in my
first django project, which incidentally was also my first experience
with ORM.

Basically I had the following class structure:

Project
 Art Project
 Research Project
 Lecture
...
And I wanted to allow the projects to link each other for a "Related
projects" feature... i figured it would be easy, just:
Project.objects.all()...but no, impossible.
Then I figured out that ORM != OO

This elementary feature should be merged into the basic django Model
class IMO.

On Jan 22, 1:00 pm, rvdrijst  wrote:
> Wow, amazing job!
>
> This addresses the big disappointment I felt when I found out django
> Model Inheritance didn't do this by default. I used some ugly
> workarounds to make it happen and this seems like the perfect
> solution. Main problem is that it requires django 1.1, I'm working
> with trunk/1.2, but I'm going to give it a try anyway.
>
> I'll keep tracking the developments on github, keep up the good work!
>
> - Robin
>
> On Jan 15, 8:55 pm, Bert Constantin  wrote:
>
> > Hello everyone!
>
> > I just uploaded a simple but mostly complete implementation of model
> > and queryset polymorphism onto github and bitbucket.
>
> > For enabled models, this implementation simply makes all references
> > to the model's objects polymorphic (be it managers/querysets or
> > relationship fields).
>
> > The prototype might be useful as a tool for concretely exploring the
> > concept of polymorphic models within the Django framework (and
> > perhaps might find use in real projects as well).
>
> > My impression is that fully polymorphic models and querysets
> > integrate very well into the Django ORM and database API. Also, with
> > Django's ORM and model inheritance system, all the heavy lifting
> > has already been done; only a rather thin layer above seems
> > to be required to get to a complete implementation of polymorphic
> > inheritance.
>
> > Below I copied the docstring of the module.
> > Near the top are a number of short examples that are good as a quick
> > overview.
>
> > The docstring can be read in a much better format 
> > here:http://bserve.webhop.org/wiki/django_polymorphic
>
> > Suggestions and criticism are very welcome.
>
> > Kind Regards,
> > Bert Constantin
>
> > GitHub:http://github.com/bconstantin/django_polymorphic
> > Bitbucket:http://bitbucket.org/bconstantin/django_polymorphic
> > Tar:http://github.com/bconstantin/django_polymorphic/tarball/master
>
> > +++
>
> > Defining Polymorphic Models
> > ===
>
> > To make models polymorphic, use PolymorphicModel instead of Django's
> > models.Model as the superclass of your base model. All models
> > inheriting from your base class will be polymorphic as well::
>
> >     from polymorphic import PolymorphicModel
>
> >     class ModelA(PolymorphicModel):
> >         field1 = models.CharField(max_length=10)
>
> >     class ModelB(ModelA):
> >         field2 = models.CharField(max_length=10)
>
> >     class ModelC(ModelB):
> >         field3 = models.CharField(max_length=10)
>
> > Using Polymorphic Models
> > 
>
> > Most of Django's standard ORM functionality is available
> > and works as expected:
>
> > Create some objects
> > ---
>
> >     >>> ModelA.objects.create(field1='A1')
> >     >>> ModelB.objects.create(field1='B1', field2='B2')
> >     >>> ModelC.objects.create(field1='C1', field2='C2', field3='C3')
>
> > Query results are polymorphic
> > -
>
> >     >>> ModelA.objects.all()
> >     .
> >     [ ,
> >       ,
> >        > (CharField)> ]
>
> > Filtering for classes (equivalent to python's isinstance() ):
> > -
>
> >     >>> ModelA.objects.instance_of(ModelB)
> >     .
> >     [ ,
> >        > (CharField)> ]
>
> >     In general, including or excluding parts of the inheritance tree::
>
> >         ModelA.objects.instance_of(ModelB [, ModelC ...])
> >         ModelA.objects.not_instance_of(ModelB [, ModelC ...])
>
> > Polymorphic filtering (for fields in derived classes)
> > -
>
> >     For example, cherrypicking objects from multiple derived classes
> >     anywhere in the inheritance tree, using Q objects (with the
> >     slightly enhanced syntax: exact model name + three _ + field
> > name):
>
> >     >>> ModelA.objects.filter(  Q( ModelB___field2 = 'B2' )  |  Q
> > ( ModelC___field3 = 'C3' )  )
> >     .
> >     [ ,
> >        > (CharField)> ]
>
> > Combining Querysets of different types/models
> > -
>
> >     Querysets may now be regarded as object containers that allow the
> >     aggregation of  different object types - very similar to python
> >     lists (as long as the objects are accessed through the manager of
> >  

Re: Fully Polymorphic Django Models: a simple implementation

[rvdrijst]

rd party
>     model as the root of a polymorphic inheritance tree::
>
>         from thirdparty import ThirdPartyModel
>
>         class MyThirdPartyModel(PolymorhpicModel, ThirdPartyModel):
>             pass    # or add fields
>
>     Or instead integrating the third party model anywhere into an
>     existing polymorphic inheritance tree::
>
>         class MyModel(SomePolymorphicModel):
>             my_field = models.CharField(max_length=10)
>
>         class MyModelWithThirdParty(MyModel, ThirdPartyModel):
>             pass    # or add fields
>
> ManyToManyField, ForeignKey, OneToOneField
> --
>
>     Relationship fields referring to polymorphic models work as
>     expected: like polymorphic querysets they now always return the
>     referred objects with the same type/class these were created and
>     saved as.
>
>     E.g., if in your model you define::
>
>         field1 = OneToOneField(ModelA)
>
>     then field1 may now also refer to objects of type ModelB or
> ModelC.
>
>     A ManyToManyField example::
>
>         # The model holding the relation may be any kind of model,
> polymorphic or not
>         class RelatingModel(models.Model):
>             many2many = models.ManyToManyField('ModelA')  # ManyToMany
> relation to a polymorphic model
>
>         >>> o=RelatingModel.objects.create()
>         >>> o.many2many.add(ModelA.objects.get(id=1))
>         >>> o.many2many.add(ModelB.objects.get(id=2))
>         >>> o.many2many.add(ModelC.objects.get(id=3))
>
>         >>> o.many2many.all()
>         [ ,
>           ,
>            field3 (CharField)> ]
>
> Non-Polymorphic Queries
> ---
>
>     >>> ModelA.base_objects.all()
>     .
>     [ ,
>       ,
>        ]
>
>     Each polymorphic model has 'base_objects' defined as a normal
>     Django manager. Of course, arbitrary custom managers may be
>     added to the models as well.
>
> Custom Managers, Querysets & Inheritance
> 
>
> Using a Custom Manager
> --
>
> For creating a custom polymorphic manager class, derive your manager
> from PolymorphicManager instead of models.Manager. In your model
> class, explicitly add the default manager first, and then your
> custom manager::
>
>         class MyOrderedManager(PolymorphicManager):
>             def get_query_set(self):
>                 return super(MyOrderedManager,self).get_query_set
> ().order_by('some_field')
>
>         class MyModel(PolymorphicModel):
>             objects = PolymorphicManager()    # add the default
> polymorphic manager first
>             ordered_objects = MyOrderedManager()    # then add your
> own manager
>
> The first manager defined ('objects' in the example) is used by
> Django as automatic manager for several purposes, including accessing
> related objects. It must not filter objects and it's safest to use
> the plain PolymorphicManager here.
>
> Manager Inheritance
> ---
>
> The current polymorphic models implementation unconditionally
> inherits all managers from the base models. An example::
>
>     class MyModel2(MyModel):
>         pass
>
>     # Managers inherited from MyModel
>     >>> MyModel2.objects.all()
>     >>> MyModel2.ordered_objects.all()
>
> Manager inheritance is a somewhat complex topic that needs more
> thought and more actual experience with real-world use-cases.
>
> Using a Custom Queryset Class
> -
>
> The PolymorphicManager class accepts one initialization argument,
> which is the queryset class the manager should use. A custom
> custom queryset class can be defined and used like this::
>
>         class MyQuerySet(PolymorphicQuerySet):
>             def my_queryset_method(...):
>                 ...
>
>         class MyModel(PolymorphicModel):
>             my_objects=PolymorphicManager(MyQuerySet)
>             ...
>
> Performance Considerations
> ==
>
> The current implementation is pretty simple and does not use any
> custom sql - it is purely based on the Django ORM. Right now the
> query ::
>
>     result_objects = list( ModelA.objects.filter(...) )
>
> performs one sql query to retrieve ModelA objects and one additional
> query for each unique derived class occurring in result_objects.
> The best case for retrieving 100 objects is 1 db query if all are
> class ModelA. If 50 objects are ModelA and 50 are ModelB, then two
> queries are executed. If result_objects contains only the base model
&g

Fully Polymorphic Django Models: a simple implementation

[Bert Constantin]

l(models.Model):
many2many = models.ManyToManyField('ModelA')  # ManyToMany
relation to a polymorphic model

>>> o=RelatingModel.objects.create()
>>> o.many2many.add(ModelA.objects.get(id=1))
>>> o.many2many.add(ModelB.objects.get(id=2))
>>> o.many2many.add(ModelC.objects.get(id=3))

>>> o.many2many.all()
[ ,
  ,
   ]

Non-Polymorphic Queries
---

>>> ModelA.base_objects.all()
.
[ ,
  ,
   ]

Each polymorphic model has 'base_objects' defined as a normal
Django manager. Of course, arbitrary custom managers may be
added to the models as well.


Custom Managers, Querysets & Inheritance


Using a Custom Manager
--

For creating a custom polymorphic manager class, derive your manager
from PolymorphicManager instead of models.Manager. In your model
class, explicitly add the default manager first, and then your
custom manager::

class MyOrderedManager(PolymorphicManager):
def get_query_set(self):
return super(MyOrderedManager,self).get_query_set
().order_by('some_field')

class MyModel(PolymorphicModel):
objects = PolymorphicManager()# add the default
polymorphic manager first
ordered_objects = MyOrderedManager()# then add your
own manager

The first manager defined ('objects' in the example) is used by
Django as automatic manager for several purposes, including accessing
related objects. It must not filter objects and it's safest to use
the plain PolymorphicManager here.

Manager Inheritance
---

The current polymorphic models implementation unconditionally
inherits all managers from the base models. An example::

class MyModel2(MyModel):
pass

# Managers inherited from MyModel
>>> MyModel2.objects.all()
>>> MyModel2.ordered_objects.all()

Manager inheritance is a somewhat complex topic that needs more
thought and more actual experience with real-world use-cases.

Using a Custom Queryset Class
-

The PolymorphicManager class accepts one initialization argument,
which is the queryset class the manager should use. A custom
custom queryset class can be defined and used like this::

class MyQuerySet(PolymorphicQuerySet):
def my_queryset_method(...):
...

class MyModel(PolymorphicModel):
my_objects=PolymorphicManager(MyQuerySet)
...


Performance Considerations
==

The current implementation is pretty simple and does not use any
custom sql - it is purely based on the Django ORM. Right now the
query ::

result_objects = list( ModelA.objects.filter(...) )

performs one sql query to retrieve ModelA objects and one additional
query for each unique derived class occurring in result_objects.
The best case for retrieving 100 objects is 1 db query if all are
class ModelA. If 50 objects are ModelA and 50 are ModelB, then two
queries are executed. If result_objects contains only the base model
type (ModelA), the polymorphic models are just as efficient as plain
Django models (in terms of executed queries). The pathological worst
case is 101 db queries if result_objects contains 100 different
object types (with all of them subclasses of ModelA).

Performance ist relative: when Django users create their own
polymorphic ad-hoc solution (without a module like polymorphic.py),
they will tend to use a variation of ::

result_objects = [ o.get_real_instance() for o in
BaseModel.objects.filter(...) ]

which of course has really bad performance. Relative to this, the
performance of the current polymorphic.py is rather good.
It's well possible that the current implementation is already
efficient enough for the majority of use cases.

Chunking: The implementation always requests objects in chunks of
size Polymorphic_QuerySet_objects_per_request. This limits the
complexity/duration for each query, including the pathological cases.


Possible Optimizations
==

PolymorphicQuerySet can be optimized to require only one sql query
for the queryset evaluation and retrieval of all objects.

Basically, what ist needed is a possibility to pull in the fields
from all relevant sub-models with one sql query. In order to do this
on top of the Django ORM, some kind of enhhancement would be needed.

At first, it looks like a reverse select_related for OneToOne
relations might offer a solution (see 
http://code.djangoproject.com/ticket/7270)::

ModelA.objects.filter(...).select_related
('modelb','modelb__modelc')

This approach has a number of problems, but nevertheless would
already execute the correct sql query and receive all the model
fields required from the db.

A kind of "select_related for values" migh

Re: Django Models

[Ludovico Magnocavallo]

James Bennett wrote:
> 
> It used to work in older versions of Django. Right now it is not
> supported, and it is probably quite dangerous to the integrity of your
> data to rely on things which accidentally "sort of work" due to the
> remains of the legacy system. Again: this is not currently supported
> by Django.

Thanks for the clarification, though it still works in trunk, not only 
in older versions. As long as it works, it's ok for me (and when it 
breaks, I will stay off trunk until I find a different way of doing the 
same thing). :)

Ludo

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django Models

[James Bennett]

On 9/24/07, Ludovico Magnocavallo <[EMAIL PROTECTED]> wrote:
> I have always read that Django does not support model inheritance or
> subclassing, but in my experience some forms of it work. Take the
> following for example, straight from a running app:

It used to work in older versions of Django. Right now it is not
supported, and it is probably quite dangerous to the integrity of your
data to rely on things which accidentally "sort of work" due to the
remains of the legacy system. Again: this is not currently supported
by Django.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django Models

[Ludovico Magnocavallo]

James Bennett wrote:
> 
> Django does not currently support any form of subclassing or
> inheritance for model classes. Please search the archives of this
> list, the django-developers list, or the Django Trac instance if you
> would like more information on this topic.

I have always read that Django does not support model inheritance or 
subclassing, but in my experience some forms of it work. Take the 
following for example, straight from a running app:

class Infrastructure(Service):

 class Meta:
 verbose_name = 'Servizio di infrastruttura'
 verbose_name_plural = 'Servizi di infrastruttura'
 db_table = 'applications_service'

I use it in a model having two ForeignKeys to the same "object", one of 
them limited with a filter, displayed as edit_inline. It was the only 
way I could make the intended design work in the admin.

If you look at the ModelBase metaclass in django/db/models/base.py from 
line 62 to 69, there's a code block that starts with the following 
comment: "Add Fields inherited from parents", that makes models like the 
one above work.

Ludo


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: Django Models

[James Bennett]

On 9/24/07, Sebastien Lannez <[EMAIL PROTECTED]> wrote:
> Is it a limitation of SQLLite ? If not, how can we implement this
> mapping ?

Django does not currently support any form of subclassing or
inheritance for model classes. Please search the archives of this
list, the django-developers list, or the Django Trac instance if you
would like more information on this topic.

-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Django Models

[Sebastien Lannez]

Hi,

I've seen something which is not very
"concept proof"... at least in
SQLLite ( hasn't been tested on PostgreSql
or MySql )

>>> class A(Models.models):
...  name = CharField(primaryKey=True)
...  field_1 = CharField()
...
>>> class B(A)
...  field_2 = CharField
...

Django will then build the folowwing tables :
CREATE TABLE xxx_A ( name VARCHAR() UNIQUE, FIELD_1 VARCHAR() )
CREATE TABLE xxx_B ( name VARCHAR() UNIQUE, FIELD_1 VARCHAR(), FIELD_2
VARCHAR() )
...
This is not safe and doen't follow the heritage
paradigm : we can have a record in xxx_A which has
the same id as a record in xxx_B ... but represents
different instance of object ( for ex. different FIELD_1) ...

We think in case of heritage, it should be better to have :
CREATE TABLE xxx_A ( name VARCHAR() UNIQUE, FIELD_1 VARCHAR() )
CREATE TABLE xxx_B ( xxx_A_name VARCHAR() CONTRAINT REFERENCE
xxx_A.name, FIELD_2 VARCHAR() )

Is it a limitation of SQLLite ? If not, how can we implement this
mapping ?

thanks,
sebastien.


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: DB to Django Models

[Jacob Kaplan-Moss]

On 12/15/06 1:38 PM, [EMAIL PROTECTED] wrote:
> Hello, i was thinking of developing some modules that did the
> transalation from any DataBase supported by Django to the Django
> Models. For example, i have a db in production but would like to use it
> with Django, then i would have to rewrite all the Data Base Abstraction
> but in the Django Models, i would like a script to do this for me, is
> just reverse engeniering.
> 
> I would like to know if anyone is working on this so i dont reinvent
> the wheel...

FYI, you're going to get a lot more help if you post this to django-users; 
django-developers is meant for discussion of developing Django itself, not 
answering questions.

Jacob

--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

Re: DB to Django Models

[Joseph Kocherhans]

On 12/15/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> Hello, i was thinking of developing some modules that did the
> transalation from any DataBase supported by Django to the Django
> Models. For example, i have a db in production but would like to use it
> with Django, then i would have to rewrite all the Data Base Abstraction
> but in the Django Models, i would like a script to do this for me, is
> just reverse engeniering.
>
> I would like to know if anyone is working on this so i dont reinvent
> the wheel...

http://www.djangoproject.com/documentation/django_admin/#inspectdb

Joseph

--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---

DB to Django Models

[[EMAIL PROTECTED]]

Hello, i was thinking of developing some modules that did the
transalation from any DataBase supported by Django to the Django
Models. For example, i have a db in production but would like to use it
with Django, then i would have to rewrite all the Data Base Abstraction
but in the Django Models, i would like a script to do this for me, is
just reverse engeniering.

I would like to know if anyone is working on this so i dont reinvent
the wheel...

Atte Carlos Zager


--~--~-~--~~~---~--~~
 You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-developers@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-developers?hl=en
-~--~~~~--~~--~--~---