EoD SQL – Getting Ready for 1.0

Wow… I never thought I’d actually say it, but thanks to a lot of prompting from a few people: EoD SQL will be moving to 1.0 in a month or two. I know it’s early to say that now, but I’ve now got a roadmap and plan for where it’s going to go. To explain in further detail:

  • A 0.8-beta release will be made with some bug fixes, and important new features
    •  The internal workaround against a bug in commons-dbpool will be included
    • QueryTool.createQueryImplementation is deprecated and will be replaced by “getQuery”
    • Full transaction support will be added (commits, rollbacks and savepoints) through a new TransactionQuery interface
    • Support for “SELECT COUNT” style queries will be added through a new @SelectPrimitive annotation
  • An API freeze will take effect directly after the release of 0.8-beta, the only code changes will be bug fixes
  • Once I am confident that the API is as bug free as I can make it, 1.0 will be released
  • The 1.0 release will include:
    • A new tutorial (more quick-start like), it probably won’t be written by me
    • A new ant script (do away with the Netbeans ant script dependency)
    • Unit tests will work on an embedded (in-memory) database
    • Some examples of how EoD SQL can be used

I was thinking in the night, and I realized that EoD SQL’s massive advantage is not it’s size or tiny overhead. It’s the simplicity, it helps you do the really horrible drudge-work of mapping your ResultSet’s to POJO’s. It’ll never be a Hibernate or JDO or TopLink, and thats exactly the way I want it. Those tools are great, but they’re far to heavy for my liking.

If I were to choose my favorite feature of EoD SQL, it would be the rubber-stamping DataIterators, they are so fast and lightweight, you just have to love them 😛