Saturday, August 1, 2015

Re: settings.py TEMPLATES DIRS

Thank you very much. I looked at that code for hours and didn't see the missing ) . A different set of eyes are really helpful.

Gary R

On Friday, July 31, 2015 at 11:59:38 PM UTC-7, Gary Roach wrote:
Hi

I'm using Django 1.8 and python 2-7 on a Debian Linux system. I am using Ninja-ide as my ide. When I enter the following in the TEMPLATES section the settings.py file I get an invalid syntax error:

'DIRS': [os.path.join(BASE_DIR, 'templates'],


Since the DIRS entry is directly out of a tutorial I'm not sure what the problem implys.


Any help will be sincerely appreciated.


Gary R


--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/3432a316-0e91-4f01-9c11-d33e0dd8ab7e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: DB Design question

On Sat, Aug 1, 2015 at 4:53 AM, James Schneider <jrschneider83@gmail.com> wrote:
> If you are talking about potentially having enough rows to extend past the
> AutoPK limits, you should consider instead using a UUID field as the PK:

note that this is only good advice if your DB handles it natively. if
not, Django will use a charField to store it and constantly
encode-decode it. If you're using PosgreSQL, then yes, UUID is great;
on MySQL, then it's far more efficient to use a BigInteger. 2^64
records still is far more than what you can store in the biggest
storage you can get.


--
Javier

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

Speedy Mail Software

Interesting. I have once contemplated building a webmail software that reads emails so customers don't lose emails upon switching webhosts. Hence, your Speedy Mail Software interests me. I'd love to be a part of the team.

Great idea it's.

Regards.
Abdulhakim

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/1eb6823e-387d-4731-9e98-9550dc55300c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Speedy Mail Software

To Django users,

I'm interested in creating a new webmail platform based on Python and Django (with jQuery and JavaScript), which will be free software & open source - Speedy Mail Software. I created a project called Speedy Mail Software on sourceforge, and I'm looking for people who will participate in writing code for this project. I renamed the project to Speedy Mail Software because Speedy Mail will be the webmail itself, based on Speedy Mail Software but with a domain and a mail server(s), so people will able to create an account there and use the mail services of the website. I'm also trying to convince computer science students from the college I graduated (The academic college of Tel Aviv - Yaffo) to participate in this project.

I also have another idea - I want to create a Python Web Toolkit, which will be similar to Google Web Toolkit - people will write code in Python, and it will run on the server side, and on the client side with JavaScript (it will compile Python code to JavaScript, like Google Web Toolkit from Java to JavaScript). Please let me know if you want to participate in any of these projects (I can also create a project for the second project in sourceforge if there will be developers interested). I will also try to ask in the main Python list (python-list@python.org), let me know if there is any other relevant list.

Thanks,
Uri.

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

Re: DB Design question

If you are talking about potentially having enough rows to extend past the AutoPK limits, you should consider instead using a UUID field as the PK:


The example in the docs uses UUID4. They index nicely and there are 2^128 (~3.4 x 10^38) UUID's available, the same as the total number of IPv6 addresses available. You'll run out of database resources (HDD, RAM, CPU) and more importantly lifespan before running out of UUID's. I've seen some larger DB applications use UUID's exclusively as their PK's for all tables.

Trying to merge fields to create uniqueness is difficult to do, wastes CPU, can be buggy if fields are missing, etc., and probably doesn't index as well.

If possible, I would also start thinking about a pruning/archiving strategy to keep your main tables as lean as possible. With a couple billion rows, you may see a bit of a stutter on queries. ;-D

-James


On Sat, Aug 1, 2015 at 1:56 AM, Stephen J. Butler <stephen.butler@gmail.com> wrote:
Why not use a BigIntegerField?

On Sat, Aug 1, 2015 at 12:06 AM, jordi collell <jordic@gmail.com> wrote:
Hi all!

I have to store spreadsheet info on a db. Some kind of quotes where the user can store distinct prices for every zone. 

After modeling the data, i have a Cell like row. (related to a zone, and with a quantity field).. something like:

zone1  1  100
zone1  2  99
zone1  3  98

Every zone is a fk... The problem is, that data grows quick.. because some quotes can have up to 65 unit fields with 70 to 100 zones.. 

Currently i have a autopk field. but I'm not sure if it will scale.. If i have 5000 users and every users makes 100 quotations.. (7000 rows on the worst case) this is 3500000000.. easy enought to get out of autoincrement fields.. 

I'm thinking on getting rid of the pk field, and use a unique together with (zone_units). do you think this is a good aproach with the orm? I saw that is not possible to make primary key fields ( with grouped fields), but perhaps I can do it with instead of declaring a int field, have a char field storing the 
%s_%s_%s ( quote_id, zone_id, units ) ... 

do you think the last could be a good aproach? 

Sure if i have to shard the data (on the future) I can do it, using this kind of keys.. Data will be queryed by zone.. (For making comparasions of quotes)

I will apreciate any help on the matter.


--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/c2a69c66-d1b8-4f08-95ed-b26fbb1d762e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

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

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

Re: DB Design question

Why not use a BigIntegerField?

On Sat, Aug 1, 2015 at 12:06 AM, jordi collell <jordic@gmail.com> wrote:
Hi all!

I have to store spreadsheet info on a db. Some kind of quotes where the user can store distinct prices for every zone. 

After modeling the data, i have a Cell like row. (related to a zone, and with a quantity field).. something like:

zone1  1  100
zone1  2  99
zone1  3  98

Every zone is a fk... The problem is, that data grows quick.. because some quotes can have up to 65 unit fields with 70 to 100 zones.. 

Currently i have a autopk field. but I'm not sure if it will scale.. If i have 5000 users and every users makes 100 quotations.. (7000 rows on the worst case) this is 3500000000.. easy enought to get out of autoincrement fields.. 

I'm thinking on getting rid of the pk field, and use a unique together with (zone_units). do you think this is a good aproach with the orm? I saw that is not possible to make primary key fields ( with grouped fields), but perhaps I can do it with instead of declaring a int field, have a char field storing the 
%s_%s_%s ( quote_id, zone_id, units ) ... 

do you think the last could be a good aproach? 

Sure if i have to shard the data (on the future) I can do it, using this kind of keys.. Data will be queryed by zone.. (For making comparasions of quotes)

I will apreciate any help on the matter.


--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/c2a69c66-d1b8-4f08-95ed-b26fbb1d762e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

Re: settings.py TEMPLATES DIRS

You're missing a closing ) after 'templates'...

-James

On Jul 31, 2015 11:59 PM, "Gary Roach" <garyroach79@gmail.com> wrote:
Hi

I'm using Django 1.8 and python 2-7 on a Debian Linux system. I am using Ninja-ide as my ide. When I enter the following in the TEMPLATES section the settings.py file I get an invalid syntax error:

'DIRS': [os.path.join(BASE_DIR, 'templates'],


Since the DIRS entry is directly out of a tutorial I'm not sure what the problem implys.


Any help will be sincerely appreciated.


Gary R


--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/35d35abb-d5d2-4108-b66e-0456e4324584%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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