My contributions to the CPAN Day celebration:
Helios 2.83 is a minor release of the Helios distributed job processing framework. It contains official SQLite support for the first time, better schema DDL for Oracle databases, and some cleanup of some files with mixed-format line endings.
Helios::Logger::HiRes 1.00 is the first stable release of a plugin module
providing enhanced logging features to the Helios framework, including
sub-second timestamp precision (provided by Perl's Time::HiRes) and a
command line log searching tool.
Thank you to everyone who contributes to CPAN, both package contributors and those that maintain CPAN itself. Happy CPAN Day everyone!
]]>For CPAN Day, I have contributed App::HTRender, a command line tool to assist development of HTML::Template-based templates. If you are building a website using HTML::Template and your data model is still fluid (or you just want to quickly test different values) you can lay out your data in JSON format and use the ht_render command to feed it to your template without having to change any of your Perl code.
Additionally, Logical Helion has released a new version of Helios, Helios 2.81. This version is largely a bugfix release, but does include a new command for retrieving jobtype information and some improvements to the helios_config_* commands.
Happy CPAN Day everyone!
]]>For more information about the Helios distributed job processing system, check out the Helios website or our project on GitHub!
]]>For more information about the Helios distributed job processing system, check out the Helios website or our Helios project on GitHub!
]]>For more information about the Helios distributed job processing system, check out the Helios website or our project on GitHub!
]]>This is highly dependent on the type of application you are writing and the RDBMS you are using. If you writing the type of application most people write, that just happens to use the database for occasional storage and retrieval of data, I agree that leaving a prepared statement around may be wasteful and may not be the best (depending on your RDBMS and environment).
But if you are the kind of soul that writes truly database-centric applications, that have data constantly coming in and going out your database, establishing prepared statements and keeping them around for the life of your process may be exactly what you want to do. It depends on your application, your data, and the RDBMS you are using.
Of course, as Joel said, the original idea was not to persist a prepared statement, but to make sure a SQL statement could be run. If the goal was to persist a prepared statement (and thus a database connection) across requests to the same process, DBI->connect_cached() and prepare_cached() are the proper methods to use, as connect_cached() would reuse the existing connection or re-establish the connection if it drops, and prepare_cached() would transparently re-prep the statement as needed. This might also necessitate moving the connect_cached() call to somewhere closer to the prepare_cached() call (as in, right before it to ensure the database is available).
]]>Regarding my own talk: After talking to several attendees about Helios, and being encouraged to be less of a "Kirk" and more of a "Picard," I've created a repository on Github for Helios. Going forward it will be easier for others to follow development, contribute, and take advantage of all the goodness Github provides. If you missed my "Distributed Processing Applications with Helios" talk and want some more information, the talk is now available on YouTube (thanks again MadMongers and all the YAPC::NA volunteers!) and the slides are available here.
IMHO, regarding this topic, there are 2 groups of programmers: those who hate and/or fear databases, and those that understand them. The former are clearly in the majority today, and work to hide away database access inside systems like ORMs so they can pretend that the database doesn't really exist, or exists as some sort of magic that only crazy people would want to deal with. Usually this attitude results in the database being neglected and eventually it bites the hand that is inadequately feeding it (which then perpetuates the opinion that databases should be hidden away and only crazy people want to work with them).
Anyway, getting back to the matter at hand. Don't let my above mini-rant fool you: ORMs and other types of database encapsulation can be a great thing if they don't get in the way and are used appropriately. I acknowledge the need for them. I do not, however, believe ORMs are appropriate in all circumstances. Database-centric applications can often become significantly harder when the database access routines are too abstracted. If you're working on the type of application where most of the data manipulation can easily be done in SQL, trying to separate your code from the database with an ORM layer will only lead to needless complications. If you are a database programmer, you can think in SQL and know what bits of your project can be easily done in SQL and what bits are more easily done in Perl (or whatever other language). Decide from that whether your project needs an ORM or some other database abstraction.
]]>