result as array

[Sergiy Zuban]

Hi Laurent,

I'm trying to find a way to fetch data as arrays rather than hashes (as statement/fast_statement does). In other words I need something similar to DBI's $sth->fetchrow_arrayref.

From what I see in the code 'fast_statement' just binds columns to hash values and technically it's possible to make this conditional and bind them to array's values if requested by -result_as.

Right now to get array I have to make alias names -> index map first and then create new array for each fetched row and populate it iterating over row's hash. This is much slower than just bind values to appropriate array's item and requires memory allocation for new array even though I don't modify the array.

Having 2 new types for -result_as (statement_array/fast_statement_array?) will make DBIx::DataModel more similar with DBI's API.

What do you think about this idea?

-- 

Sergiy Zuban

[Laurent Dami]

Le 14.05.2013 19:57, Sergiy Zuban a �crit :

> --
Hi Sergiy,

The benefit of using an ORM is to give you objects on which you can
invoke methods. If all you want is raw data, then maybe you are better
off by calling DBI directly. Furthermore, all type conversions in DBIDM
depend on handlers associated to column names; so if that information is
lost, it is no longer possible to apply those handlers. This would mean
that data in array results would not be the same as data in hash
results, which would be quite confusing. So I'm not much in favor of
adding arrays as a new feature in DBIDM API.

This being said, there are 2 ways to get arrays while still working with
DBIDM :

a) use DBIDM to generate the request, and then use DBI to fetch the results.

my $sth = $source->select(-where => \%criteria, -result_as => 'sth');
while (my @row = $sth->fetchrow_array) {...}

b) use a fast statement, and just exploit the hash values

my $fast_stmt = $source->select(-where => \%criteria, -result_as =>
'fast_statement');
while (my row = $fast_stmt->next) {
say join ";", values %$row;
}

Solution b) has the advantage of applying the column handlers, while
solution a) only gives you raw data. Solution b) should be quite fast
because it reuses the same memory locations for each row; but solution
a) is probably event faster. Have a look at
https://github.com/damil/compare-ORM if you are interested in benchmarks.

Cheers, Laurent D.

[Sergiy Zuban]

Laurent,

In my case I don't have column handlers, but need to process big amount of data as fast as possible (and keep using ORM to query db). Probably I'll go ahead with  -result_as => 'sth' and fetch data vi DBI.

Thank you for so fast reply.

--
Sergiy Zuban

On Tue, May 14, 2013 at 2:19 PM, Laurent Dami <lauren...@free.fr> wrote:

--

--- You received this message because you are subscribed to the Google Groups "dbix-datamodel" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dbix-datamodel+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.