[Dbix-class] A "short" year-end summary (and long live perl 5.8 :)

[Peter Rabbitson]

Greetings fellow RDBMS haters!

2011 is about to roll away before you know it, so I figured I should
jolt down a short summary and hint at some things to hopefully come
to life in 2012[1]. All of these ramblings should soon end up in
DBIx::Class::Manual::* documents, but the writeups are still too
rough to actually publish.

* What's new and notable

So 2011 wasn't too great for DBIC. It wasn't horrible either mind you:
- We finally got full support for custom JOIN conditions on relationships
- The new quote_names => 1 connection attribute obviated the guesswork
   necessary to supply quote_char =>
- A new column_info flag retrieve_on_insert was added to facilitate
   easy retrieval of column defaults besides the primary key (it even
   uses INSERT ... RETURNING under the hood for engines that support it)
- All limit/offset values are now proper bind params, which dramatically
   reduces the amount of statements to prepare when dealing with paged
   resultsets
- Support for 2 new RDBMS engines:
    Firebird over DBD::Firebird and
    MSAccess over DBD::ODBC and DBD::ADO
- and as usual a ton of bugs and corner cases were fixed

So yes, not impressive but not a standstill either :) There are couple
items we really hoped to see in the list above, but alas they didn't
get the tuits they deserved. So I will touch on them right now:

* Perl support policy

The short version is that contrary to the general trend on CPAN, the
*core* functionality of DBIC will continue to be supported on perl
versions all the way back to 5.8.3[2] as long as practical. Given how
loaded and revolting this statement is to some, here is the long
version:

The core purpose of DBIC is to take the tedium out of accessing data
stored in a RDBMS. As such it should take into consideration not only
the quirks of different database engines, but also the very realistic
scenario of a user having at his disposal a clunky MySQL v3 combined
with a long-bearded perl 5.8.4. Denying the joy of using DBIC to the
less fortunate fellow programmers is seen as a form of laziness, given
the minimal[3] amount of effort necessary to support older perls.

What this means for a regular DBIC user is that if you have perl 5.8.x
and you encounter some sort of installation or runtime problem, *WE BY
ALL MEANS WANT TO HEAR FROM YOU*. I feel this point needs to be
emphasized, since way too often I encounter folks on IRC giving up
on seeking support before even trying, based *only* on the fact that
heir perl is "old" and "unsupported". So if you are in the unfortunate
situation of being stuck on an older perl - do file bugs, and they
will get fixed.

Another important point is that we extend this policy not only to DBIC
itself, but also to its entire depenency chain. In other words if you
end up on a fresh install of perl 5.8.3 (unlikely but still), you
should have the expectation that `cpan DBIx::Class` will just work.
If it doesn't - let us know and a solution will be found.

* Near term development roadmap

While these are just rough points, they nevertheless represent the
basic plan for near-future DBIC development.

- Bring back the old-style from syntax, lost somewhere around 0.08115,
allowing people to upgrade from older 0.08xxx (or even 0.07xxx)
versions. At this point this is the only known API regression left,
which is incidentally what is holding up the 0.08200 release.

- After release of 0.08200 the development will be split into a maint
and blead track, following the model of perl5 development. This will
both allow us to dump new features into 'blead' quicker and more
recklessly, and will also allow folks in slow-to-upgrade production
environment to benefit from bugfix-only changes landing into maint.
The proposed versioning scheme is to overload the meaning of -TRIAL,
while still using the traditional _xx versioning for dev releases:

   0.08200 ~ 0.08249             - maint
   0.08250-TRIAL ~ 0.08299-TRIAL - blead
   0.08300 ~ 0.08349             - maint
   ... etc

The reason for this "version number conservation" is that while we do
add improvements to DBIC all the time, none of the proposed "quantum
leap" features (see next heading) are yet ready for prime-time. Hence
we will continue with conservative versioning, not unlike the way the
linux kernel used the 2.6 model for a while.

- Compile a comprehensive and *self-maintainable* list of TODOs. This
has been long in the making, and is almost ready for prime time. The
reason this isn't as simple as "jolt some things down" is that such
effort invariably turns into waste after a while. TODOs are left
unmaintained, wikis are left to spamrot etc. The plan here is to tie
a machine-parsable part to each entry of the TODO list, and make the
whole thing an integral part of the `make dist` process. Hopefully we
will know before the end of January how well this will work.

- ... that's about it for the short term plans, also see [1] :)


So that's all I can think of off the top of my head. Feel free to ask
questions if any on the list or on IRC, we are always happy to help.

Happy new year and happy search()ing in 2012!


[1] That is until we all die a fiery death by filled up transaction
logs come next December.

[2] Currently DBIC is fully functional on 5.8.1 and 5.8.2 as well,
however these perls sport some really scary bugs in the method
dispatch. So while in reality DBIC will keep trying to support
everything back to 5.8.1, the support commitment only extends to
5.8.3.

[3] "Minimal" is a relative term. We are not trying to ridicule
other CPAN projects which deemed the support cost too high for the
volunteer resources at their disposal.