ORM options for Python server to Flex client

Let's say Python is your solution of choice for backend development and Flash technology is your preferred client. If your project uses a database, you will need a good ORM solution at some point. The options are many and here are a few of them:

• WebORB by MidnightCoders
• Django built-in ORM
• SQLAlchemy ORM

There are surely other options (roll your own, anybody?) but these come to mind readily. Now, how to choose which one? Let's look at the capabilities of each:

WebORB

Pros: MegaOptions, from RTMP Server to Secure Transactions and lots more, turnkey CRUD, GUI admin, GUI performance, plug and play, one-click ORM generator, ORM testing suite. The list goes on...

Cons: Costs a pretty penny last I checked. Could be considered bloaty. I would have to hear some performance testers weigh in on this.

Verdict: Great at limiting server-side development to a minimum. Great full-service solution. Would be a strong contender in a rich media studio or design shop.

====================================

Django built-in ORM

I'll use it when the time comes. Methods to replace Django's ORM outright with SQLAlchemy have been detailed on some intrepid developer blogs. I would rather not customize the framework too much, as it introduces potential troubleshooting down the line. You can use Django ORM and an addition ORM library like SQLAlchemy interchangeably, so that would be my first choice if going this route.

=====================================

SQLAlchemy

A very robust open source option with a surfeit of detailed documentation, this one regularly gets my vote. It is sufficiently explicit to require familiarity to use, but not too steep a curve to get started quickly. Extensions like Elixir simplify the code at the expense of greater abstraction. This is a case of using the right tool for the right project, so feel free to learn more about both.

MAMP with mod_wsgi

Once you get a database set up, sqlite or otherwise, you can use it with Django applications. You can serve Django directly from a command line or through Apache. In either case you will need Django to be installed. From a command line, simply run the django server and browse to it:

django-admin.py runserver

If your production server is going to be Apache, your best bet is to run Django under Apache locally. To do this you need a helper library for Apache to use. The de facto solution is mod_wsgi.

mod_wsgi

To get started with mod_wsgi, typically you download mod_wsgi from Graham Dumpleton's Google Code repository, you go to your command line, you untar it, you configure it, you make it and you make install it. This makes the code library available to wsgi-enabled services, in effect allowing you to run Django on Apache.

When you make install mod_wsgi, it places the libraries in your /lib directory. Then it links to your Apache directory where OSX keeps it, /usr/libexec/apache2. Installation includes automatic detection, or you can use some optional flags to specify resource paths, detailed in the wsgi installation guidelines.

Now your OSX Apache has modwsgi installed, but the Apache version in MAMP does not. To verify this, try making a Django app and serving it via MAMP. First, make a new django app in an appropriate directory:

django-admin.py startproject myproject

Next, open and modify the config for your MAMP Apache app, located in /Applications/Mamp/conf/apache/httpd.conf. For that matter, have a look at what your OSX Apache instance has in its config file. It is private/etc/apache2/httpd.conf. Searching for wsgi in this file yields:

LoadModule wsgi_module libexec/apache2/mod_wsgi.so

Looks good even if the relative directory location may be an issue. Insert this info into the MAMP httpd.conf and test it. Actually, there is no need because it will not work. This is due to the structure of MAMP and its proprietary use of Apache. Unlike a full install of Apache, the folders in MAMP have a different structure and are optimized to run modularly. Consequently, you cannot append a flag to your configure command in this manner:

./configure --with-apxs=/usr/sbin/apxs2-worker

because the structure available to Apache is not in MAMP, so detection will fail.

This leaves a couple of options. Either reconstruct some of the MAMP Apache folders so detection will succeed or look for another solution. Considering the evident lack of general success from many Google searches, I am letting this fish off the hook. Feel free to leave a comment if you know a way to make it work.

As a final consideration, mod_python appears to be a lot quicker to set up with MAMP. That could be a candidate if you are in a pinch. Otherwise, if serving Python via Apache is your goal, I recommend using the resources included with OS X and skipping MAMP altogether.

MAMP with sqlite

If you want a local enviro to test in, MAMP for Mac is a good way to go. Right out of the box, you get Apache, MySQL, SQLite and PHP support. Also in the mix is python 2.5, which ship with OS X.

With several apps at the ready, how do you get your head around the new environment? Piece by piece. First let's look at SQLite.

SQLite

Have a good read at some typical command line options to get you up and running. Go ahead and try it out. See if you can create a db, add some values, retrieve the values.

When you store a database, it is stored in the current directory. You can see what that is by using the command pwd, aka print working directory. Further documentation is available on the SQLite site. If you decide command line is not your style, one option is the SQLite Manager for Firefox. It's not for remote db admin but it'll do for local scenarios.

In summary, getting up and running with sqlite is simple. MAMP comes with MySQL, so that is another available option.

Send Failed Flex Error in WebORB

Is Flex via WebORB middleware sending a message similar to this?

Error: Server reported an error - Send failed

The resolution will most likely consist of looking over your xml declarations, both for the declared endpoint URI and the service it requests.

If you face such a challenge, read the very useful orientation by WebORB creator and principal Mark Pillar. Check this post to confront the matter head on and move forward.

Good luck.

Magento and PHP5 Install Memory Error

If, when installing Magento Ecommerce, you experience some variant of this message:

Fatal error: Allowed memory size of 16777216 bytes exhausted (tried to allocate 24 bytes) in /home/userdir/sites/mywebsite.com/public_html/magento/lib/Zend/Db/Statement/Pdo.php on line 232

The solution is simple. Just go to your

/etc/php5/apache2/php.ini*

and set memory higher than the default of 16M. The error trace indicates a minimum requirement of 24M for successful installation.‡

But you knew that already, right?

^{* php.ini may be in a different directory
‡ full disclosure: I allotted 64MB since the slice I'm using has 512MB available.}

Proxy Debuggers and Flex NetConnection Debugger

With AS2, setting up a NetConnection between a Flash Player and a server running Flash Remoting could be streamlined using the Flex NetConnection Debugger. It was included with Flex 1.0 ca. 2005 and only required two short steps to enable. Many developers included it in their remoting utilities shortlist.

Now that we're living in a CS4 age, the playing field has changed. All the functionality of the NetConnection Debugger has been integrated into the Flash library. This means that instead of launching separate apps for debugging, you can simply mock up a routine using calls to available library components.

Good enough, but if you prefer a dedicated debugging app, NetConnection Debugger is out, and some other options are in its place.

Midnight Coders App Puncher

Much has been said about Midnight Coders' contributions to RIA development. Their middleware tier is arguably the best muscle around and can be a real time-saver. I'm speaking of WebORB, but particular to debugging, have a look at another of their products, the RIA App Puncher.

Charles Web Debugging Proxy

Link to Charles.

ServiceCapture

Link to ServiceCapture.

Virtualenv vs Virtual-Python

If you harbor multiple versions of Python, as is usually a good idea, you can go at least two routes:

1. Virtualenv
2. Virtual-Python

Both organize your all-important PYTHONPATH environment variable and keep your preferred python executable at the ready. This in turn makes module add-ons, test projects and installations easy.

On that note, Easy_install recommends virtual-python.py as a quick way to keep organized. It is indeed easy to set up and concise as well.

Another option, the one I use incidentally, is virtualenv. Once installed, all you need to do to switch active versions is activate it via the command line.

In a newly created virtualenv there will be a bin/activate shell script, or a Scripts/activate.bat batch file on Windows.

On Posix systems you can do:

$ source bin/activate

Even better than that is Doug Hellmann's virtualenvwrapper which, as he describes, allows you to set a working python environment with a single command. It's easy to set up as well, just a couple of lines into your bash script and bombs away, your virtualenv is wrapped.

With these options, you can initiate new projects and test new python libraries without any conflicts or misgivings. Try it out sometime. What have you got to lose?