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. _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/[email protected]
