Django and primary keys versus surrogate keys
What Django does to my primary key problem is magnify the effects ofchanges and errors in two ways. First, the admin interface allowsconvenient direct insertion of data into the database, includingimmediately creating foreign key dependencies. People sometimes makemistakes when typing things in; the fewer steps between typing insomething and having it wind up in the database, the fewer chancesyou have of catching your error. In a slower environment I might havenoticed some of my typos after I had written the file of loader commandsor SQL
A little advantage of Django's automatic primary keys
If you don't specify manual primary keys on your schema tables,Django will automatically give you one in the standard form of anauto-incrementing integer. I believe that this is standard ORM behaviorand you'll find it in pretty much any ORM interface. After coming to my SQL foreign key realization I've realized that there's an additional advantage to having this sortof primary key (over and above the ability to fix oopses in what isnormally that table's primary key).
The
There are two sorts of standards in the world
There are two sorts of standards in the world; let us call them forcedstandards and voluntary standards.
With a forced standard, someone makes you adhere to the standard. If youdon't, you can't get your product licensed or certified or whatever, andyou can't sell it or give it away or do whatever you want to do withit. Sometimes this is forced because of legislation, and sometimes thisis just forced through the marketplace; no one will buy your productif it is
An obvious realization about SQL foreign keys
In the process of writing the last entry , I finally realized something about SQLforeign keys. Specifically, about what you could call their lifetime, byanalogy to object lifetimes in garbage collected languages.
Everyone knows (hopefully) that you don't want to have long-livedobjects hold references to what should be short-lived objects. In a GC'denvironment such (strong) references convert the short-lived objectsinto long-lived ones; they can't be GC'd before the long
Two things I have discovered about Django schema design
I've now gotten far enough into my application to have stubbed my toes on a few beginner'smistakes in Django and ORM schema design. Fortunately I've done thisduring development instead of production, so it's merely a valuablelearning experience.
First, I should never make schema fields into explicit primary keys,no matter how attractive it seems and how SQL-proper it is. EspeciallyI should not do this when the field is shown to or used by humans.Otherwise, sooner or later
The amusement of minimalist spam
I just received the following extremely minimalist and to the point spammessage:
This is to notify you of a payment Order of usd$8.5m created into Atm Cardin your name from the skye bank, you are advice to reconfirm us 1 Name 2Address 3 Phone 4 ID.
Some days, I like to think that the advance fee fraud spammers are justas tired of the whole thing as the rest of us are.
On programming (and me)
Every time I wind up doing a substantially amount of coding , I end up rediscovering how muchI enjoy programming and how rewarding it feels. It's more than justthe monkey rewards from doing things and getting feedback, it's allsorts of pleasure rolled up in a big complicated ball that I just lovewithout being able to describe why I find it so absorbing. I just likeprogramming, even if I forget how much I do when I haven't done it for awhile.
(Sometimes I
Not very much about Solaris NFS filehandles
A lot of Unix systems have NFS filehandles that are easy to recognize anddecipher, at least to the extent of easily mapping filehandles to theserver's filesystems (such information is very useful for things liketroubleshooting just which server filesystem is seeing lots of NFStraffic from one particular client). Solaris does not.
The basic structure of a Solaris NFS v3 filehandle is as follows, atleast as of Solaris 10 U8 or so:
| (bytes) | (what) |
| 4 | overall filehandle length in XDR byte |
The various ways of writing a modern Python web app
As the flipside version of last entry , supposethat you want to write some sort of web thing in Python and you want toknow what to use to do it. Broadly speaking, you have the following mainoptions:
- Write it as a straight CGI.
This is probably the simplest approach for small stuff if youdon't already have a WSGI server or a framework environment setup that you can just plug small applications into. Python'score library has plenty of batteries for this environment.
- Write your own
The modern Python web application stack (as I understand it)
Someone recently asked me what the modern Python equivalent of CGI was. The answerstarted out simple but the more I wrote the more complicated it got,until it wound up here.
At their base, modern Python web applications are written to aninterface called WSGI , the 'Web Server GatewayInterface', a specification for the Python environment that webapplications run in. WSGI is fairly low level (roughly on the level ofCGI) and generally good, although it has a number of annoying cornercases that everyone ignores