Rants, musings, and [sometimes] useful articles from Greg Taylor.
Rants, musing, and [sometimes] helpful stuff
I am pleased to announce the release of django-eve-proxy 0.1. This isa simple proxy/cache app for Django that you may drop in to assist in accessing the API through your Python modules, or with a urls.py entry, via HTTP.
Although young, django-eve-proxy should be fully functional and ready to go. All comments, feedback, and suggestions are appreciated.
For the use of fellow Djangonauts out there, I introspected and fixed upCCP’s SQL dump of EVE Online data. This means you can now get access to everything from the comforts of the Django ORM.
The project is still very new, and I’m not even sure it’s going to be attractive given the table layout. At this point, it is a bunch of introspected models and a fixed up database dump. I’ll be adding convenience methods, __unicode__ functions, and etc with time to make it more friendly. Check it out at:
http://code.google.com/p/django-eve/
For now this will only work on Postgres until some kind soul wants to get the MySQL or SQLite dumps fixed up (some tables need ‘id’ primary keys).
Just looking through DjangoSites.org and Googling around, I’mabsolutely puzzled by the lack of Django-based browser games. It is such an idea platform for developing these, yet there are only a few that are actually open to the public (some of which aren’t in English, and are thus inaccessible to me). There seem to be a few games out there in French, Chinese, and some other things I don’t really recognize, though.
Here are a few games in English I’ve been able to round up:
I’m particularly interested in anything open-source, as I’d love to contribute from time to time, but I’d love to hear of any playable games that I have missed, or any open-source games in development. As far as close-sourced games in development, they’re not of much interest to me if they’re at least not open for testing. Without access to the source or a reachable site, it’s as good as vaporware (and many of them never see completion).
So speak up, let me know if there’s something that I’ve completely missed!
I just thought I’d take a moment to give everyone a heads up thatMulti-Model Inheritance fixture dumping and loading is now fixed, as per Russ Magee’s changeset 7600. This fixes a subtle problem that some of you may have seen in the form of foreign keys pointing to the wrong objects after using loaddata to restore an app.
The “pk” fields (usually ‘id’) in the serialized dump weren’t being loaded correctly, meaning that the objects id fields defaulted to the table’s incremental numbering rather than using the number specified in your object’s fixture’s “pk” field. This would not be an issue unless you deleted an object in your original table and thus had a gap in your primary keys (IE: they were no longer un-interrupted and sequential).
Let’s say you have three objects, 1 (Apple), 2 (Banana), 3 (Orange). You delete Banana (2) and now have entries with keys of 1 and 3 (non-sequential). Some other arbitrary models point at 1 and 3, and you now dumpdata your Fruit app and re-load it. The loader ignores the fact that Orange’s PK is 3 and instead just adds it right behind apple as PK 2 (sequential, the default behavior for primary keys when no value is specified). All of your other relations pointing at Orange in other tables are now broken, and you’re likely to see Exceptions thrown or models pointing to the wrong fruit (if you had more fruit defined to be compacted into PK 3).
I have a feeling I didn’t explain this well. In the event that you’d like further elaboration, see the Django-Users post where it’s outlined a little beter. For those using Multi-Model inheritance and fixtures, this was a definite show-stopper.
A big thinks goes out to Russ Magee for fixing this!
Django is able to run on a number of different web servers, databases,and operating systems. This flexibility lends itself to a lot of diversity within the community, but what kind of combinations are the most common?
The developers seem to suggest that Apache2 + mod_python + Postgresql seem to be the recommended setup, but undoubtedly there are lots of others. I’ve heard mentions of lighttpd, FastCGI, nginx running on Windows, Linux, Mac OS X, Unix/BSD, and others. There is even a useful page on the Django wiki with some of the arrangements along with instructions for each.
So I pose the question to you, what do you run on? What operating system, server, and database? If you’re feeling really ambitious, I’d be interested in hearing how your setup has worked for you.
As for this site, it’s hosted on Debian running Apache 2, mod_python, SQLite. For a simple, low traffic site like this, it has worked quite well.
Rants, musings, and [sometimes] informative stuff from Greg Taylor.
