Re: Types of projects Django is not well suited for?
On Dec 26, 12:08 pm, "ak" <[EMAIL PROTECTED]> wrote: You can search through this mailing list, I remember one guy about a few months ago that compared django development to his previous php expirience and found that django is now very well for him. Unfortunatelly I have no link and I don't remember what it exactly was about but it definatelly happened in the current list. On November 28 I started a thread with Subj "Why not Django". I tried to compare Django and TurboGears. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Why not Django
Victor Ng wrote: > On 11/30/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > Here you mean SELECT FOR UPDATE, right? > > No, I mean SELECT. OK. Then another part of my answer is applied. > The use case is two users are viewing the same record, and they both > go to update the same record. Yes, this is the use case for the described method of avoiding long-lasting transactions and still garantee that only the intended information is modified. The method is not universal, since it does not give a user any garanteed time of data validity. This time is necessary to have for applications like sales. For that kind of application my first move would be to go for a stateful connection (https?). Next, a method of cleaning from overrun transactions is needed... > That means the view code would SELECT the records into the view. I'm > assuming you're doing SELECT FOR UPDATE and UPDATE on the POST > request/response cycle. If you're actually doing a SELECT FOR UPDATE > on the initial request, I can't see how you're holding on to your > connection between request response cycles. The assumption is correct. Can you still see any flaws in the sense that the user will not be informed that his action resulted in an attempt of altering a changed row? All the Django examples I saw suffer from these flaws in your example (or I misunderstand how Djando works). I concider the optimistic approch also good enough for most cases, and frankly I think it should be implemented by Django (and others) automagically, of course with a possibility to have it off. > vic Thanks for your comments! V.Chukharev --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Why not Django
Victor Ng wrote: > If user A and user B are editting the same records and you enter a > race where they do this: > > A) retrieve record Here you mean SELECT FOR UPDATE, right? > B) retrieve record Same here, right? > A) delete record > B) update record As SELECT FOR UPDATE starts a transaction, these two are in concurrent transactions, right? > The select for update that user B uses will succeed since the select > will simply return 0 rows. The update will succeed because 0 rows are > updated successfully. The update will not be tried if its SELECT FOR UPDATE returns 0 rows, since there is nothing to update. The UPDATE will be made only if SELECT FOR UPDATE returns exactly 1 row. Otherwise the transaction is rolled back and the client informed that he needs to try again (and why). The transaction is commited after the last table is UPDATED. On any error the transaction is rolled back. Similar for DELETE. Sorry, I was to be explicite that SELECT FOR UPDATE must return 1 row. Thus, in your example either DELETE or UPDATE will fail with a possibility for a good error message for the client. > SELECT FOR UPDATE really only helps if the SQL commands are running > concurrently. They are running concurrently in your example. At least I don't see why not. In case you mean by 'retrieve record' something else than SELECT FOR UPDATE, e.g. simple SELECT for GET (i.e. for the client to decide what to do with this row). We do not start any (lasting) transaction at this moment, just because we don't need to. One more clarification (correction). I said 'all information from all fields..', but I have examples of fields which might be (or might be not) omitted from the SELECT FOR UPDATE. For one, the last modification timestamp field. > vic > > -- > "Never attribute to malice that which can be adequately explained by > stupidity." - Hanlon's Razor --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~--~~~~--~~--~--~---
Re: Why not Django
Victor Ng wrote: > I find this interesting too since the use of numeric instead of a > float is the right decision most of the time. > > If you're dealing with money at all - you absolutely cannot use float, > you *must* use fixed decimal types or you risk getting into all kinds > of really terrible rounding errors. Even if you are right and the use of numeric is the right decision, still naming the fixed decimal type 'float' is, well, surprising ;-) > I'm frankly surprised that a scientific computing app is using float > with any degree of success. It's a lot easier to use float where fixed suits better, than other way round. > The long running transaction support discussed in point #1 will fail > if data is modified between loading the initial page on GET and Yes, it will fail, with a good explanation for the user, and that is the desired behavior. And it is not a long running transaction in the dbms. > submitting data on the POST. A simple SELECT FOR UPDATE doesn't solve > this problem at all, you actually need a full blown unit of work > pattern implemented on the server side that ties to your session. I will really appreciate an example showing when SELECT FOR UPDATE is not sufficient. GET is not important, it does not start a transaction in db. POST can be constructed even without contact to the database, it only should contain all information from all fields of the affected rows of all the affected tables (it's OK if the client just guessed all this information correctly), and the new information for UPDATEs. No long-lasting transactions involved. The session is needed only for authentication. I think I can create a model where the mentioned 'optimistic approach' will fail, but the full described approach seems to me correct. I want to know what I am overlooking, please help me to understand. > vic > > Using floating point math is well > > -- > "Never attribute to malice that which can be adequately explained by > stupidity." - Hanlon's Razor Best regards, V.Chukharev --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
Why not Django
I appologize for rather provocative subject line. I just want to tell all why I could not use Django and had to use TurboGears instead, even though I like Django more. I wrote this memo for internal use, and then desided to post it inhere. I have been involved in an initial development of database with a web front-end. The original prototype of the system was written practically in pure Python. We decided to start the new project from evaluation of available development kits like Django and TurboGears (all other candidates were rejected at very early stage and will not be mentioned). I'm going to share here the reasons why now we have decided to go with TurboGears and not with Django. The project we are doing is dealing with results of experimental research work. It should store and manipulate great variety of numerical data including but not limited to real and complex scalar values, one-, two-, and many-dimensional arrays, and other structured information. The plan is to build the core part so that addition of one more type of data will be as simple as possible. Basing on this goal and previous experience, the priorities in evaluation were set as follows. (First mark is for Django, second for TurboGears; '-' means lack of the feature or worse than avarage, '+' - the feature is available or better than avarage, '0' - at avarage level.) 1. ACID compliance. Most important. ++ 2. Inheritance for tables in DB. Most important. -+ 3. Arrays of integers and floats. Very important. -- 4. In case of arrays absence - binary data. Important.-- 5. Numeric data. Important. -+ 6. Potential for generic templates. Important.++ 7. Ready set of parameters for data and rendering defaults. 00 Important. 8. Good error diagnostic messages. Important. +0 9. Documentation. Important. +0 10. Overall consistency. Less important. +- 11. Good examples and discussion lists/forums.00 Less important. 12. Installation. Least important.++ The importance marks are not for general use, just for this particular project. For our next project they might change. Now lets go over the list step by step. 1. ACID compliance. Here I mean not only atomicity, consistency, isolation, durability of every change made by the program to DB. The system should also check, that the data were not changed between retrieving the information by the client and the beginning of the changing operation after the client's reply.Given the stateless nature of http, I see only one good approach to it. The information obtained from DB for update, is sent to the client in two separate pieces, as a form for corrections, and as a set of hidden fields. When the client clicks on OK button, the program can start a transaction by doing 'SELECT FOR UPDATE' with the original data from the hidden fields, then update data and close the transaction. Any error should lead to the transaction rollback. I did not find anything like that neither in Django nor in TurboGears. On the other hand, a bit less reliable optimistic approach can be easily implemented both in Django and TurboGears. An additional field with timestamp of last change is added to each table and this value is used to verify that data were not changed before updating. As to other parts of ACID compliance, both competitors do good job and differ only in details of implementation. Draw. 2. Inheritance for tables in DB. Structure of the information in the project allows to organize it in a set of tables related by inheritance. PostgreSQL has this inheritance in declaration of tables. Similar inheritance is implemented in TurboGears (both in SQLObject and SQLAlchemy). Django also has inheritance in the class declaration corresponding to the tables, but use of it leads to creation of separate, unconnected tables, so that the derived table has all columns of the parent table plus columns declared in the derived class itself. What can be used in Django to build similar structure is OneToOneField. But the implementation of the manipulators lies on the programmer. A minor complication is the name of OneToOneField. It should be not id (as all other primary key columns are) but parent_id, where parent is the name of the related table. Probably, this is forced by some reasons for other usages of the field, but in simulating inheritance in the desired sense this needs special care. This point is definitely won by TurboGears. 3. Arrays of integers and floats. PostgreSQL allows to use arrays of numerical data as column types. This is very helpful for storing regular numerical data. Neither TurboGears nor Django implement these types. 4. Binary fields. These fields could be used to store structured data in case of absence of numerical arrays and other
