Better Django projects monitoring
Hi Djangofans, We have posted instructions how to integrate Django with AlertGrid for better controlling for your Django based projects. http://alert-grid.com/integrations/frameworks/django/ It allows to upgrade standard email-on-error mechanism as well as can help monitor your critical scheduled jobs. There is a free account provided with no time limits so it might be enough for most of companies. Regards, Lukasz -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
bigint + postgre (+ south) lacks sequence for primary keys
Hi, I have just migrated my project to Django 1.2.1 and changed some of primary keys to big integers (id = models.BigIntegerField(primary_key = True)). South migration (from scratch) went without any problems and I have also bigint id fields created on my database. The problem is that all my tests (related with models) crashed very loudly, After some investigation I figured out that there are no sequences created for my new id fields. Is this a bug in Django? South? Or maybe I did something wrong in this process? My setup is: Django 1.2.1 South 0.7.1 Postgre 8.3 -- You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
Re: Time lookup
OK, situation I deal with is that I have many events, each event is scheduled for some date and time (like 1 april 2009, 1pm). I want to make query that retrieve all events that are scheduled between 3pm-5pm (na matter what day) or are scheduled before 2pm (no matter what day) or sth simillar. It might sound quite strange but in case of that project this is quite obvious situation. I can split datetimefield to datefield and timefield but I will miss some other advantages then, I think. I just wondered if there is some way to get time part from datetimefield (like using python: datetime.now().time()) in Django query. Anyway, thanks for response Regards, L On 31 Mar, 17:04, Brian Neal <bgn...@gmail.com> wrote: > On Mar 31, 5:31 am, LD <l.dzied...@gmail.com> wrote: > > > OK, but Django do not provide 'time' lookup so my problem is 'how to > > retrieve time part of datetime field in a query' > > Ok, then why are you storing date and time together when all you care > about is time? To me, when you have a DateTimeField, that represents a > point in time. It doesn't make a lot of sense to ask: "does this point > in time occur less than 14:00 hours." 14:00 hours on what day? Today? > Yesterday? That is the source of friction for me. Maybe you could > explain your model a bit more. > > Maybe you should consider using a TimeField instead, then your query > would be more natural. > > But if you really do need to store dates and times together, then yes, > I don't think there is an easy way to just query on the time part of > the DateTime field. You might look into the new F() syntax, but you > might just have to write your own SQL. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Time lookup
OK, but Django do not provide 'time' lookup so my problem is 'how to retrieve time part of datetime field in a query' On 31 Mar, 04:29, Brian Neal <bgn...@gmail.com> wrote: > On Mar 30, 10:12 am, LD <l.dzied...@gmail.com> wrote:> Hi, > > > I don't have idea how to do simple task. > > I have model with DateTimeField and I want to retrieve all objects > > that have time for example lower than 2pm. > > > I know about Django queryset lookup like year, month, day. Is there > > something similar but for time? If not what is the simplest way to > > accomplish that? > > > So it would be great to do something like this: > > MyModel.objects.filter(date_field__time__lt == datetime.time(14,0)) > > assuming of course that MyModel.date_field is models.DateTimeField > > Well, the model field is storing a date and a time. So you can't just > compare that against a time, I don't think. You need to pick a day and > a time. And then you can do the filtering, you've almost got the > syntax right. Something like this should work: > > MyModel.objects.filter(date_field__time__lt=datetime.datetime.(yy, mm, > dd, 14, 0)) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Time lookup
Hi, I don't have idea how to do simple task. I have model with DateTimeField and I want to retrieve all objects that have time for example lower than 2pm. I know about Django queryset lookup like year, month, day. Is there something similar but for time? If not what is the simplest way to accomplish that? So it would be great to do something like this: MyModel.objects.filter(date_field__time__lt == datetime.time(14,0)) assuming of course that MyModel.date_field is models.DateTimeField Thanks, Regards, Lukasz --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: django. postgre and errors (integrity errors not raised as expected in unit tests)
OK. solved. The problem was that I did something like this: class MyModel(models.Model): field = #this field is marked as unique and then in tests: sid = transaction.savepoint() ml1 = MyModel(field = 'a') ml1.save() m2 = MyModel(field = 'b') self.assertRaises(IntegrityError, m2.save) tranasction.avepoint_rollback(sid) and that was case where I had problem. When I moved savepoint after m1 was create - then it is ok. Best Regards, Luke On 23 Mar, 13:16, LD <l.dzied...@gmail.com> wrote: > Thanks for response, > > savepoint api looks nice and in fact it did the thing for some tests. > But for some other I still got the same error - looks strange since > tests are trying to do simmilar logic. > > I thought that problem was in some logic in test setUp, but again in > both test cases there is setUp and they look simmilar as well. > > I also found that running single test is OK (manage.py test app > TestCase.test_name), but running whole test case (manage.py test app > TestCase) leads to error. > > Do you have any ideas? And once again thanks for response > Luke > > On 21 Mar, 02:00, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > > > On Fri, 2009-03-20 at 16:26 -0700, LD wrote: > > > Hi, > > > > Today I enforced strange situation, hope it is strange only for me nad > > > you will quickly tell me what stupidness I am doing. > > > > Well, today I have switched from sqlite to postgre. Everything was > > > perfect since I've tried to run set of unit tests for my project. > > > > Every time my tests deals with situation where IntegrityError is > > > expected test execution is stopped with error: > > > Error: Database test_my_project couldn't be flushed. Possible reasons: > > > * The database isn't running or isn't configured correctly. > > > * At least one of the expected database tables doesn't exist. > > > * The SQL was invalid. > > > Hint: Look at the output of 'django-admin.py sqlflush'. That's the > > > SQL this command wasn't able to ru > > > The full error: current transaction is aborted, commands ignored > > > until end of transaction block > > > > When I look into postgre logs I can see that db tried to do operation > > > that I was expected. I don't know why with sqlite IntegrityErrors > > > where raised normally and with postgre thet are not. > > > The issue is that PostgreSQL wants you to explicitly clean up the > > transaction that is open after an error like this occurs. SQLite doens't > > have transactions for normal operations (it does have transaction-like > > behaviour for writes, but it's not quite the same thing), which is why > > you didn't see it there. > > > Secondly, Django runs the whole test suite inside a bunch of large > > transactions. We clean up at the end of each test by rolling back the > > transaction. > > > If you're intentionally causing IntegrityErrors in your tests -- which > > isn't a bad things at all -- you just have to do a little preparation. > > The simplest solution is to use savepoints. Your tests will still run > > across all database backends, since Django provides "do nothing" > > implementations for backends that don't care about this (those where > > transactions aren't supported or aren't visible to every cursor -- > > technical details you don't have to worry about). The only slight > > problem is PostgreSQL prior to 8.0 (the 7.x didn't support savepoints). > > > Right now, savepoint handling isn't documented, mostly because I was > > waiting to check that the API didn't suck. Also, I'm not really sure > > what to do about the PostgreSQL 7.x situation, since we still nominally > > support that (there are existing non-end-of-lifed production-worthy > > distributions that use it). > > > However, to see how to use them in tests, have a look at, for example, > > django/tests/modeltests/force_insert_update/models.py. There are a few > > tests in there where we are trying to force an IntegrityError. > > > If you're using unittests, rather than doctests, the same logic still > > applies. You set up a savepoint before starting and clean it up > > afterwards. > > > Regards, > > Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: django. postgre and errors (integrity errors not raised as expected in unit tests)
Thanks for response, savepoint api looks nice and in fact it did the thing for some tests. But for some other I still got the same error - looks strange since tests are trying to do simmilar logic. I thought that problem was in some logic in test setUp, but again in both test cases there is setUp and they look simmilar as well. I also found that running single test is OK (manage.py test app TestCase.test_name), but running whole test case (manage.py test app TestCase) leads to error. Do you have any ideas? And once again thanks for response Luke On 21 Mar, 02:00, Malcolm Tredinnick <malc...@pointy-stick.com> wrote: > On Fri, 2009-03-20 at 16:26 -0700, LD wrote: > > Hi, > > > Today I enforced strange situation, hope it is strange only for me nad > > you will quickly tell me what stupidness I am doing. > > > Well, today I have switched from sqlite to postgre. Everything was > > perfect since I've tried to run set of unit tests for my project. > > > Every time my tests deals with situation where IntegrityError is > > expected test execution is stopped with error: > > Error: Database test_my_project couldn't be flushed. Possible reasons: > > * The database isn't running or isn't configured correctly. > > * At least one of the expected database tables doesn't exist. > > * The SQL was invalid. > > Hint: Look at the output of 'django-admin.py sqlflush'. That's the > > SQL this command wasn't able to ru > > The full error: current transaction is aborted, commands ignored > > until end of transaction block > > > When I look into postgre logs I can see that db tried to do operation > > that I was expected. I don't know why with sqlite IntegrityErrors > > where raised normally and with postgre thet are not. > > The issue is that PostgreSQL wants you to explicitly clean up the > transaction that is open after an error like this occurs. SQLite doens't > have transactions for normal operations (it does have transaction-like > behaviour for writes, but it's not quite the same thing), which is why > you didn't see it there. > > Secondly, Django runs the whole test suite inside a bunch of large > transactions. We clean up at the end of each test by rolling back the > transaction. > > If you're intentionally causing IntegrityErrors in your tests -- which > isn't a bad things at all -- you just have to do a little preparation. > The simplest solution is to use savepoints. Your tests will still run > across all database backends, since Django provides "do nothing" > implementations for backends that don't care about this (those where > transactions aren't supported or aren't visible to every cursor -- > technical details you don't have to worry about). The only slight > problem is PostgreSQL prior to 8.0 (the 7.x didn't support savepoints). > > Right now, savepoint handling isn't documented, mostly because I was > waiting to check that the API didn't suck. Also, I'm not really sure > what to do about the PostgreSQL 7.x situation, since we still nominally > support that (there are existing non-end-of-lifed production-worthy > distributions that use it). > > However, to see how to use them in tests, have a look at, for example, > django/tests/modeltests/force_insert_update/models.py. There are a few > tests in there where we are trying to force an IntegrityError. > > If you're using unittests, rather than doctests, the same logic still > applies. You set up a savepoint before starting and clean it up > afterwards. > > Regards, > Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
django. postgre and errors (integrity errors not raised as expected in unit tests)
Hi, Today I enforced strange situation, hope it is strange only for me nad you will quickly tell me what stupidness I am doing. Well, today I have switched from sqlite to postgre. Everything was perfect since I've tried to run set of unit tests for my project. Every time my tests deals with situation where IntegrityError is expected test execution is stopped with error: Error: Database test_my_project couldn't be flushed. Possible reasons: * The database isn't running or isn't configured correctly. * At least one of the expected database tables doesn't exist. * The SQL was invalid. Hint: Look at the output of 'django-admin.py sqlflush'. That's the SQL this command wasn't able to ru The full error: current transaction is aborted, commands ignored until end of transaction block When I look into postgre logs I can see that db tried to do operation that I was expected. I don't know why with sqlite IntegrityErrors where raised normally and with postgre thet are not. Can't wait to hear your opinions. Luke --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
What can be done about all the spam in django-users?
Hi, If the spam can't be stopped, the unsubscribe is the only option I guess, eh? Cheers, --ldl On 1/19/07, Nancy Brad <[EMAIL PROTECTED]> wrote: Media Mall Toolbar : Advanced 1-click System to the Following Items : - 200 Live TV Channels - FM Radio With alot of Radio Stations and You Can Add More. - Live WebCams around The World - Tools and Essentials as : Online Spyware Scanners,Online Virus Scanners and Online Firewall Services - Website Translator to any Language - Free Web Design Tools - MediaMall Toolbar is a free comparison shopping assistance tool provides you with best available online prices . It uses a state-of-the-art and is simple and intuitive to use. MediaMall presents the following features: automatically compares prices on electronic devices such as PDAs, MP3 players, DVD, computer accessories, printer accessories, PCs, Macs,and monitors; automatically compares prices on new books; dynamic toolbar which is displayed only when truly needed to spare unnecessary waste of screen area - Fun Section for Online Games , Comedy Flashes , Cartoons & more - Email Notifier for all Your Accounts - PopUp Blocker & Net Tracking Remover - Weather after providing your zip code to get your local weather. You Can Download That Toolbar Free from : http://www.download.com/Media-Mall-Toolbar/3000-12777_4-10624080.html The Media Mall Toolbar Has Certified The "SoftPedia 100% Clean" Award: http://www.softpedia.com/progClean/Media-Mall-Toolbar-Clean-62625.html Best Wishes , > -- --- LD Landis - N0YRQ - de la tierra del encanto 3960 Schooner Loop, Las Cruces, NM 88012 651/340-4007 N32 21'48.28" W106 46'5.80" "If a thing is worth doing, it is worth doing badly." –GK Chesterton. An interpretation: For things worth doing: Doing them, even if badly, is better than doing nothing perfectly (on them). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
[Django-users] how about a subject prefix???
Dear Django-users List Mangler, Would it be possible to have something like the above subject prefix put on the Django lists? Please? Would help visually enhance Django stuff from other noise. TIA for your consideration. Cheers, --ldl -- --- LD Landis - N0YRQ - de la tierra del encanto 3960 Schooner Loop, Las Cruces, NM 88012 651/340-4007 N32 21'48.28" W106 46'5.80" "If a thing is worth doing, it is worth doing badly." –GK Chesterton. An interpretation: For things worth doing: Doing them, even if badly, is better than doing nothing perfectly (on them). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Is the software behind the Djangobook available?
Hi, I am referring to http://www.djangobook.com/en/beta/ I am very impressed with the way that the User Community Django book site interacts with the authors and reviewers of the work in progress. Is the application driving that site available for somewhere? I have a need For this type of software, to use for a book that is being collaboratively written. Cheers, --ldl -- LD Landis - N0YRQ - de la tierra del encanto 3960 Schooner Loop, Las Cruces, NM 88012 651/340-4007 N32 21'48.28" W106 46'5.80" "If a thing is worth doing, it is worth doing badly." –GK Chesterton. An interpretation: For things worth doing: Doing them, even if badly, is better than doing nothing perfectly (on them). --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
