|laziness, impatience, and hubris|
Re: Re (tilly) 1: DBI vs DBIx::Recordset vs princepawn vs chromaticby princepawn (Parson)
|on Mar 08, 2001 at 21:50 UTC||Need Help??|
And yes, I identified many of the same items that chromatic did. If you are lining up long chains of variable names and hoping that you have the same number, in the same order, then you are going about things in the wrong way.I don't agree with you. Such programming is possible in DBI and in some cases is appropriate. I see DBI just like I see assembly language or something. It isn't very structured, but it is very fast. In some cases, where you want optimal speed, then a "portable database assembly language" like DBI is the tool of choice
It is not hard for me to look at the list of things that you are saying are improved in DBIx::Recordset and tell that the abstraction, at least as you are describing it, would not be appropriate for the actual situations that I am coding against at work. Please describe these situations in detail and show why, otherwise I am afraid I have nothing as hard data showing the inadequacy of Recordset in application-level programming. OPEN CHALLENGE. PLEASE FILL IT.
Furthermore understand, that DBIx::Recordset inherits from DBI so you can always call retrieve the underlying DBI database handle and make DBI method calls.
And princepawn, I sincerely hope that you read this, get off your high horse, and learn something useful. what high horse? I do agree with your discussion of misuse of globals... and the newer version of this article corrects this, but under editorial pressure to get the article out the door fast, I left the old code in there. I have learned a lot about globals since then, especially from you. As a result, all my programs use strict; use warnings; use diagnostics;
Your entire idea of selecting * from a table and having your code figure out how to handle that is a stupid idea. I spent a good deal of energy in that post trying to explain to you why that was bad and what a saner approach is. "Stupid idea" is a qualitative, unsubstantiated assertion. Maybe you could instead show why it is a bad idea and show all of us what would be better. I am afraid that you are under-informed here, and part of it has to do with how I presented Recordset perhaps. The fact is that binding a typeglob to a select leads to a tie of a scalar, array and hash within the namespace of that typeglob. The scalar is used for object-oriented access to the table, the array is used to (lazily and memory-efficiently) iterate through the set of records matching the query and hash is used to access the columns of the current records in the recordset. This is in contrast the the manual decision-making required with DBI in which you must decide whether to get your data back as an array, arrayref, or hashref. So the bottom line is the process is automatic.
Apparently you didn't listen. Somehow I am not surprised. You don't appear to spend much time listening. You think that the rest of the world should listen to you though. Then why waste your energy talking to what you believe is a brick wall? I don't ignore people, I am here, particularly in this thread, to hear WITH LIVING PROOF AND EXAMPLES, of what you think about the two modules and their relationship and I would like to hear about other related modules, such as DBIx::Abstract and BingoX::Carbon. What is your goal in responding to me? I am perplexed
The fact is that right now you clearly have so little appreciation of basic principles of how to program that I don't care about your opinion on what modules you like. You simply lack the skill level necessary to make judgements on that that I would find even remotely useful. Who was that talking about a high horse? <grin>