ORLite::Pod - Fixing the MASSIVE design mistake in ORLite

Alias on 2009-01-14T02:14:28

My ORLite ORM system (which seems to be turning into one of those projects that I'm in love with but nobody else quite seems to get) has made my life so much better.

But since I started using it as the data storage layer for Padre I've confirmed my suspicion that I made a massive mistake in the design.

My original goal was to produce an ORM that would compliment and imitate the best features of SQLite. It would be simple, fast, very very small, self-contained, and easy to use.

It's certainly met most of those goals.

Creating an light, simple and fast ORM class tree in one line of code with very little memory load works perfectly. It can handle SQLite databases living at arbitrary remote URLs, and it supports schema versioning so that you can automate the schema migration and upgrade processes.

The problem with all this wonderful automation is that because there's no actual code created anywhere nobody (and some days that also includes me) has any idea how to use the ORM classes that ORLite creates.

Most of the generated classes don't get their own .pm files, the set of methods that get generated varies subtly based on read-only vs read-write access to the SQLite database, and writing documentation in the ORLite module itself can confuse things even more, because you end up with a mix of "How to use ORLite docs" and "How to use the classes it creates" documentation.

As far as I can tell, none of the 25 or so committers on the Padre project have ever actually written code to use the Padre::DB layer beyond cut and pasting from stuff I had written already.

If code is generated in a forest and it doesn't come documented, does anybody care?