(Fwd) DBI support for arrayshash
- Forwarded message from Dmitry Trofimov [EMAIL PROTECTED] -
From: Dmitry Trofimov [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: DBI support for arrayshash
Hello.
Please include function selectall_arrayhash in next versions of DBI.
It should be useful for all people.
#
# Get all hash records in array
#
sub selectall_arrayhash{
my $self = shift;
my @res;
my $sth = $self-{dbh}-prepare(shift);
$sth-execute(@_);
while(my $data=$sth-fetchrow_hashref){
push @res, $data;
};
$sth-finish;
return [EMAIL PROTECTED];
}
Regards Dmitry.
- End forwarded message -
Re: Fwd: it works, but...
On Sun, Jul 03, 2005 at 03:47:11AM -0500, Gerardo Santana G?mez Garrido wrote:
-- Forwarded message --
From: Gerardo Santana G?mez Garrido [EMAIL PROTECTED]
Date: Jun 29, 2005 1:46 PM
Subject: it works, but...
To: [EMAIL PROTECTED]
I'm sending you attached the output of it_works.
DBD::Informix works fine, except that it's taking twice the time than
ESQL/C when I SELECT from a table and do a while($ref = $stmt-fetch)
{ }
This table has aprox. 250 fields and 8000 rows. It takes 199 seconds
for perl to execute the select and fetch all the records, while for
the program in ESQL/C (that selects, fetch, aggregates and prints a
report) it takes 72 seconds.
Any ideas?
Can you post the code that's calling the DBI? That's probably where
most of the time is being spent.
A very simple way to check that is to set the DBI_PROFILE env var to 1
before running the script. Let us know what it says.
Tim.
Re: Fwd: it works, but...
On 7/20/05, Tim Bunce [EMAIL PROTECTED] wrote:
On Sun, Jul 03, 2005 at 03:47:11AM -0500, Gerardo Santana G?mez Garrido wrote:
-- Forwarded message --
From: Gerardo Santana G?mez Garrido [EMAIL PROTECTED]
Date: Jun 29, 2005 1:46 PM
Subject: it works, but...
To: [EMAIL PROTECTED]
I'm sending you attached the output of it_works.
DBD::Informix works fine, except that it's taking twice the time than
ESQL/C when I SELECT from a table and do a while($ref = $stmt-fetch)
{ }
This table has aprox. 250 fields and 8000 rows. It takes 199 seconds
for perl to execute the select and fetch all the records, while for
the program in ESQL/C (that selects, fetch, aggregates and prints a
report) it takes 72 seconds.
Any ideas?
Can you post the code that's calling the DBI? That's probably where
most of the time is being spent.
A very simple way to check that is to set the DBI_PROFILE env var to 1
before running the script. Let us know what it says.
Tim.
Thanks. This is it:
DBI::Profile: 215.947677s 93.72% (8587 calls) test.pl @ 2005-07-20 18:21:3
That was with my original query, that joins four tables.
This is with a simple select * from table, where table has around 300 fields:
DBI::Profile: 143.146600s 91.56% (8588 calls) test2.pl @ 2005-07-20 18:33:00
By the way, I have just tested the same on Solaris 2.6 with IDS 7.30
and I get this:
DBI::Profile: 1.697653s 59.09% (198 calls) test2.pl @ 2005-07-20 19:31:22
So, I guess my HP environment is broken somewhere.
--
Gerardo Santana Gómez Garrido
http://www.openbsd.org.mx/santana/
Entre los individuos, como entre las naciones, el respeto al derecho
ajeno es la paz -Don Benito Juárez
Re: DBI v2 - The Plan and How You Can Help
On Thu, Jul 07, 2005 at 08:32:47AM -0500, Jones Robert TTMS Contractor wrote: When I go to the donation page and attempt to make a donation, the drop-down box does not give DBI as a valid recipient. Is it possible several people may not have donated as they noticed the same results, or maybe they did and it all went into the Perl Development Fund instead? The Perl Foundation default donation page doesn't list the DBI Development Fund (for various reasons). To get that option you can use http://dbi.perl.org/donate/ which will redirect you[1] Thank you. Tim. [1] https://donate.perlfoundation.org/index.pl?node=Contribution%20Infoselfund=102 -Original Message- From: Tim Bunce [mailto:[EMAIL PROTECTED] Sent: Friday, July 01, 2005 7:06 PM To: perl6-language@perl.org; dbi-users@perl.org Subject: DBI v2 - The Plan and How You Can Help Once upon a time I said: http://groups-beta.google.com/group/perl.dbi.users/msg/caf189d7b404a003?dmode=sourcehl=en and wrote http://search.cpan.org/~timb/DBI/Roadmap.pod which yielded: https://donate.perlfoundation.org/index.pl?node=Fund+Drive+Det ailsselfund=102 (A little over $500 of that I effectively put in myself.) My *sincere* thanks to all those who donated to the fund, especially individuals. I had hoped for more corporate response with less from individuals and I'm touched by the personal generosity shown. I've not drawn any money from it yet and doubt that I will myself. (I'm considering suggesting that the Perl Foundation make payments from the fund to people making specific contributions to the DBI. I'm thinking especially of work on a comprehensive test harness. But I'll see how the developments below pan out before making specific arrangements.) So, that lead to: http://groups-beta.google.com/group/perl.dbi.dev/browse_frm/th read/ef14a9fc0a37441f/fb8fe20a86723da0#fb8fe20a86723da0 Which sums up fairly well where I'm at: DBI v1 will rumble on for Perl 5 and DBI v2 will be implemented for Perl 6. --- digression --- At this point I'd like to make a slight digression to highlight the amazing work going on in the Perl 6 community at the moment. Especially Autrijus' Pugs project which has brought Perl 6 to life. Literally. Take a look at: http://pugscode.org/talks/yapc/slide1.html http://use.perl.org/~autrijus/journal and especially: http://use.perl.org/~autrijus/journal/24898 Yes, that really is Perl 6 code using the DBI being executed by Pugs. That's great, and I was truly delighted to see it because it takes the pressure off the need to get a DBI working for Perl 6 - because it already is working for Perl 6. At least for Pugs. (The Ponie project is also likely to provide access to Perl 5 DBI from Perl 6 by enabling future versions of Perl 5 to run on Parrot.) --- digression --- I have recently come to an arrangement that will enable me to put some worthwhile development time into DBI (still very much part-time, but enough to give it focus and move forward). My initial goals are: 1. to work on a more detailed specification for the DBI v2 API that takes advantage of appropriate features of Perl 6. 2. to work on a more detailed specification for the DBDI API http://groups-beta.google.com/group/perl.perl6.internals/msg/c fcbd9ca7ee6ab4 3. to work on tools to automate building Parrot NCI interfaces to libraries (such as database client libraries, obviously :) But I'm hoping you'll join in and help out. I've kept an eye on Perl 6 and Parrot developments but I'm no expert in either. What I'd like *you* to do is make proposals (ideally fairly detailed proposals, but vague ideas are okay) for what a Perl 6 DBI API should look like. Keep in mind that the role of the DBI is to provide a consistent interface to databases at a fairly low level. To provide a *foundation* upon which higher level interfaces (such as Class::DBI, Tangram, Alzabo etc. in Perl 5) can be built. So, if you have an interest in the DBI and Perl 6, put your thinking cap on, kick back and dream a little dream of how the DBI could be. How to make best use of the new features in Perl 6 to make life easier. Then jot down the details and email them to me (or to dbi-users@perl.org if you want to kick them around in public for a while first). I'm about to fly off for two weeks vacation (in a few hours), blissfully absent of any hi-tech gear beyond a mobile phone. When I get back I'll gather up your emails and try to distill them into a coherent whole. Have fun! Tim.
Re: DBI v2 - The Plan and How You Can Help
On Sat, Jul 02, 2005 at 01:06:02AM +0100, Tim Bunce wrote: Once upon a time I said: I'm back now and, after digesting a small mountain of non-DBI related emails, I'll start digesting all your replies and getting up to speed with Perl 6. Many thanks to all who replied on and off-list. Tim.
Re: RFC on other database wrapper modules
It's a shame I think you only got the two responses back, but I don't really think I know enough to contribute to what you are asking. Gav... - Original Message - From: Darren Duncan [EMAIL PROTECTED] To: dbi-users@perl.org Sent: Thursday, July 21, 2005 9:50 AM Subject: Re: RFC on other database wrapper modules | Thanks for the 2 responses I got for this email. They are aggregated | below for your perusal. Next I will go and write my Lightning Talk. | -- Darren Duncan | | -- | | At 7:05 AM -0400 7/19/05, John Siracusa wrote: | On 7/19/05 5:05 AM, Darren Duncan wrote: | Also list the features the modules do provide that you wouldn't want | to give up, particularly if very few modules support those features | and others don't. | | I use a module (Rose::DB) that parses and formats db-specific column values | for me: various kinds of dates, SETs, arrays, all the crazy db-specific | data types that are a pain to manually parse and then format. Very few DBI | abstraction modules provide this feature, but IMO it's essential. | | -John | | -- | | At 2:58 PM + 7/19/05, Terrence Brannon wrote: | Darren Duncan [EMAIL PROTECTED] writes: | | This is a quick RFC concerning database wrapper modules and | frameworks, large and small, which are quite common on CPAN; | specifically it concerns such things that are not any of my creations. | | I am going to propose a Lightning Talk for OSCON in the next few days | (deadline is July 22, a practice is on July 19th) on the subject of | databases and SQL generation and portability and such things. | | | The best survey of database wrappers I have seen is here: | | http://search.cpan.org/~evo/DBIx-SQLEngine-0.93/SQLEngine/Docs/Related.pod | | -- | | | -- | No virus found in this incoming message. | Checked by AVG Anti-Virus. | Version: 7.0.323 / Virus Database: 267.9.2/53 - Release Date: 20/07/2005 | | -- No virus found in this outgoing message. Checked by AVG Anti-Virus. Version: 7.0.323 / Virus Database: 267.9.2/53 - Release Date: 20/07/2005
DBI- finish question
I understand that finish frees resources. What happens if the script dies under error? Do the finishes function as transactional boundaries and cause commits?
RE: DBI- finish question
No, commit() or setting AutoCommit on the database handle are the only ways to commit. - Ron Reidy Lead DBA Array BioPharma, Inc. -Original Message- From: Denesa K Shaw [mailto:[EMAIL PROTECTED] Sent: Thursday, July 21, 2005 11:21 AM To: dbi-users@perl.org Subject: DBI- finish question I understand that finish frees resources. What happens if the script dies under error? Do the finishes function as transactional boundaries and cause commits? This electronic message transmission is a PRIVATE communication which contains information which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. Please notify the sender of the delivery error by replying to this message, or notify us by telephone (877-633-2436, ext. 0), and then delete it from your system.
DBI DBD::Oracle Question
Hi, I was recently going through the process of manually installing DBI 1.48 and DBD::Oracle (I prefer the manual route), and couldn't complete the install due to items missing from @INC. I'm working on a Linux box. The only way I was able to correct the problem was by either modifying the test cases to put the missing pieces into @INC or by running the 'make install' before running the 'make test', which somewhat defeats the purpose. I'm just wondering if people have seen things like this as well, or if this is even something worth looking into? ~Sharon
RE: DBI DBD::Oracle Question
Which linux? What is the output of 'perl -V'? What was missing? - Ron Reidy Lead DBA Array BioPharma, Inc. -Original Message- From: Smith, Sharon Michelle (OSLO) [mailto:[EMAIL PROTECTED] Sent: Thursday, July 21, 2005 1:14 PM To: dbi-users@perl.org Subject: DBI DBD::Oracle Question Hi, I was recently going through the process of manually installing DBI 1.48 and DBD::Oracle (I prefer the manual route), and couldn't complete the install due to items missing from @INC. I'm working on a Linux box. The only way I was able to correct the problem was by either modifying the test cases to put the missing pieces into @INC or by running the 'make install' before running the 'make test', which somewhat defeats the purpose. I'm just wondering if people have seen things like this as well, or if this is even something worth looking into? ~Sharon This electronic message transmission is a PRIVATE communication which contains information which may be confidential or privileged. The information is intended to be for the use of the individual or entity named above. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. Please notify the sender of the delivery error by replying to this message, or notify us by telephone (877-633-2436, ext. 0), and then delete it from your system.
Re: RFC on other database wrapper modules
Darren Duncan wrote: the focus or sole content of my Lightning Talk (assuming it is accepted) will be to introduce my 'Rosetta' plus 'SQL::Routine' modules I'm looking forward to it. Beginning DBI users at OSCON might also consider attending my tutorial The Basics of Perl DBI, given on Monday morning, see : http://conferences.oreillynet.com/cs/os2005/view/e_sess/6910 Anyone for a DBI BOF? please post at http://conferences.oreillynet.com/pub/w/38/bof.html Thanks! -- Jeff
Re: DBI v2 - The Plan and How You Can Help
At 8:24 PM + 7/21/05, Terrence Brannon wrote (on poop-group): At 7:05 AM -0400 7/19/05, John Siracusa wrote: I use a module (Rose::DB) that parses and formats db-specific column values for me: various kinds of dates, SETs, arrays, all the crazy db-specific data types that are a pain to manually parse and then format. Are sets and arrays useful types? I don't think so. You're looking at it the wrong way: are SETs and arrays used in real database installations running real apps? Yes, they are. Maybe they shouldn't be or whatever, but I need code that helps me deal with my reality, not the world as I might imagine it, were I consulted from day one ;) The date functionality you speak of might belong in DBI proper perhaps? I argued for that a while ago but it was deemed inappropriate for something as low-level as DBI. I can see some truth to that argument, but I'd still like to see some sort of official hooks in DBI, if not actual implementations. Anyway, even ignoring dates, the bottom line is that every database has its own funky data types, and syntaxes to go with them. I don't want to have to remember the N ways to write a BIT constant in Postgres, and I certainly don't want to have to parse them manually each time I want to do something with such a column value. I want my DB abstraction layer to help me here. If it's not DBI proper, then it should be something above it. -John
DBI BOF at OSCON 2005
At 3:42 PM -0700 7/21/05, Jeff Zucker wrote (under a different subject): Anyone for a DBI BOF? please post at http://conferences.oreillynet.com/pub/w/38/bof.html Thanks! Great idea! I would be willing to submit the application form for this and/or host it, unless someone else wants to do that. I will try to be fair and unbiased. My personal preference for a date is Thursday evening at 7:30 or later, because that night is after the Lightning Talks. But if a majority prefers another night (there is Monday and Wednesday to choose from), then so be it. As far as I can see, there are no conflicts with the schedule on any night except with other BOFs. Evening events on the main schedule for Wednesday and Thursday both start at 6pm, so there should be time for people that want to attend both those and the BOFs. For whomever submits the form, it may be helpful to answer the main questions by committee. Therefore, feel free to write in what you think should be said for the main questions, which are reproduced below. Personally, I'm inclined that this BOF should be for advanced topic discussions, largely for people that have a medium to high level of experience, or at least already know the basics. Something partly to make up for the lack of an Advanced DBI talk this year. This would complement Jeff Zucker's The Basics of Perl DBI tutorial on Monday, which is more geared to beginners. The BOF could discuss in person things like DBI v2, or whatever wrapper modules, or whatever attendees want, really. -- Darren Duncan -- Title of proposed BOF: Describe the people who would be interested in attending this BOF: Which evenings(s) are you available to host your BOF? Full description of this BOF Maximum 250 words, about 35 lines. Brief description of this BOF Maximum 50 words, about 7 lines. Anything else we should know about your proposal?
