Re: Is their an easy way to implement an ordered list of, say, urls in Django

On Wed, 26 Dec 2012 23:31:00 -0500, Doug Snyder <webcoach101@gmail.com>
declaimed the following in gmane.comp.python.django.user:

> OK, cool, thanks.
> I'll keep in mind the custom SQL solution for the future but for this
> project I think I do the editing on the front end ( see below)
> I have a strange background where I'm learning django but have never used
> SQL outside of django's ORM.
> I haven't played around with custom SQL since I don't know it.
> Is it just a matter of basically copying the code you listed above and
> putting that somewhere in my model?
>
There is a way to specify raw SQL in Django... You would have to
ensure it is using the proper table/column names, and probably whatever
placeholder the DB-API layer uses for the DBMS.

> Yea, sorry I wasn't very clear. I am thinking of doing the editing on the
> front end using KnockOutJS which is a ModelView ViewModel implementation
> in javascript. So I would pass the list to KnockOutJS in a mirrored data
> structure and edit it there. SO I guess it is like dumping the whole list,
> but since I want the user to edit it on the front end the ineficiency is
> acceptable. I guess Javascript lends itself better to editing and inserting
> to an ordered list than SQL does and the data has to go the front end
> anyways.

<shudder>

It may just be me, but the idea of sending a massive data stream to
a browser just to allow for "ordered inserts", followed by returning the
full stream to the server where the entire data set is written to the
database (somehow replacing the previous contents) just seems very error
prone: network drop mid-stream, or worse -- how do you reconcile
multiple edits (two people "inserting" one record each; the server now
gets a whole batch from user-1 which had a new record in, say, position
4; then gets a batch from user-2 that added a record at position 3 [the
old 3 is no coming back as record 4 -- how do you prevent overwriting
the previous user's new record 4 with a copy of old record 3]).

{apologies -- that paragraph got rather convoluted}

Do you intend to lock the entire data set for whatever duration it
takes for the first user to download, peruse/edit, and finally return
the data? What if they go to lunch in the meantime?

Even using raw SQL (the "update sequence"/"insert new") can cause
problems with dual editors... Since a sequence number update could
require the second editor's data to have a different insert position.
The good thing -- the SQL method is a short fast transaction that only
needs to be locked for a fraction of a second.

You could, perhaps, handle multiple editors by sending a "database
version" (cookie or hidden field on the web page) which is just an
incrementing count of database (table) writes... When an editor returns
an edit, you check the hidden version against the current database value
-- if the count is the same, you increment the count and store the
changes (as a transaction). If the count differs, it means some other
person submitted an edit while you [other editor] were looking at the
data -- server should redirect to a web page that advises "database was
changed, verify your edits are still valid", displays the refreshed
contents of the database, and maybe displays the user's edits below for
reference.
--
Wulfraed Dennis Lee Bieber AF6VN
wlfraed@ix.netcom.com HTTP://wlfraed.home.netcom.com/

--
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+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/django-users?hl=en.