Re: highscalability.com report

2012-04-17 Thread Fred Moyer
On Mon, Apr 16, 2012 at 3:39 AM, Vincent Veyron  wrote:
> Le jeudi 12 avril 2012 à 13:14 -0400, eric.b...@barclays.com a écrit :
>> Well, finding (good) developers is certainly an issue.
>>
> Over the years, I have seen more than one of those being driven out of
> the field by the inane management that most developers toil under. And
> considering how demanding it is to be a good programmer, I can see why
> they give up : you just can't have both.
>
> On the other hand, I see scores of good developers in open source
> projects (their products certainly are very good)

I think the one of the main reasons this dichotomy exists is that in
open source, developers spend the bulk of their time programming. In
closed source work, developers start out doing a lot of programming,
but over time spend less time programming, and more time going to
meetings, writing status reports, and filling out HR paperwork,
killing processes on overloaded dev servers, etc. The best development
managers I've seen shield their programmers from those tasks and allow
them to get work done. There is no agile silver bullet to make
programmers more effective except giving them uninterrupted time to do
their jobs.


Re: Safe handling of an SQL query

2012-04-17 Thread Michael Ludwig
Bonjour Vincent,

Vincent Veyron schrieb am 16.04.2012 um 22:21 (+0200):
> 
> I guess (in the message I forwarded to the list) Andreas is right,
> though : the only way to be safe is to keep control of the query,
> therefore keep it on the server.
> 
> I am doing this now, but passing parameters to the query becomes
> cumbersome :-(

If you haven't done that already, you could take a look at the following
three modules. While I have never used any of them I've bookmarked them
for future opportunities …

https://metacpan.org/module/SQL::Interp
https://metacpan.org/module/SQL::Abstract
https://metacpan.org/module/DBIx::Simple

Best,

Michael


Re: [mp2] Test fails with undefined symbols on AIX [mod_perl 2.0.5/apache-2.2.22/perl-5.14.2]

2012-04-17 Thread Peter Heimann
On 04/07/2012 12:36 AM, Fred Moyer wrote:
> RC3 is now available - see d...@perl.apache.org for the link.  

I get similar results for RC5.

Can't load
'/home/user/tmp/mod_perl-2.0.6-rc5/blib/arch/auto/APR/Brigade/Brigade.so' for
module APR::Brigade: rtld: 0712-001 Symbol modperl_croak was referenced
  from module
/home/user/tmp/mod_perl-2.0.6-rc5/blib/arch/auto/APR/Brigade/Brigade.so(),
but a runtime definition
  of the symbol was not found. at
/usr/local/perl/lib/5.14.2/aix-thread-multi/DynaLoader.pm line 190.
 at /home/user/tmp/mod_perl-2.0.6-rc5/t/lib/TestAPRlib/brigade.pm line 15
Compilation failed in require at
/home/user/tmp/mod_perl-2.0.6-rc5/t/lib/TestAPRlib/brigade.pm line 15.

Brigade.so references modperl_croak:

% nm blib/arch/auto/APR/Brigade/Brigade.so | grep modperl_croak
.modperl_croak   T9088
.modperl_croak   t9088  40
modperl_croakU   -
modperl_croakd3228   4

The symbol is defined in mod_perl.so:

% nm src/modules/perl/mod_perl.so | grep modperl_croak
.modperl_croak   T   48736
modperl_croakD   50728  12

Shouldn't Brigade.so then have a library dependency from mod_perl.so?
Apparently, it doesn't:

% ldd blib/arch/auto/APR/Brigade/Brigade.so
blib/arch/auto/APR/Brigade/Brigade.so needs:
 /usr/lib/librtl.a(shr.o)
 /unix

> Do you have another set of APR libraries installed, perhaps with the 
> packaging system that comes with AIX? It looks like mod_perl was built 
> against a different set of APR libs than is being loaded at runtime. 

No, not in the AIX standard lib directories or in the LIBPATH.

-- 
Peter Heimann


Re: highscalability.com report

2012-04-17 Thread Vincent Veyron
Le mardi 17 avril 2012 à 10:04 -0700, Fred Moyer a écrit :
> On Mon, Apr 16, 2012 at 3:39 AM, Vincent Veyron  wrote:
> > Le jeudi 12 avril 2012 à 13:14 -0400, eric.b...@barclays.com a écrit :
> >> Well, finding (good) developers is certainly an issue.
> >>
> > Over the years, I have seen more than one of those being driven out of
> > the field by the inane management that most developers toil under. And
> > considering how demanding it is to be a good programmer, I can see why
> > they give up : you just can't have both.
> >
> > On the other hand, I see scores of good developers in open source
> > projects (their products certainly are very good)
> 
> I think the one of the main reasons this dichotomy exists is that in
> open source, developers spend the bulk of their time programming. In
> closed source work, developers start out doing a lot of programming,
> but over time spend less time programming, and more time going to
> meetings, writing status reports, and filling out HR paperwork,
> killing processes on overloaded dev servers, etc. 

That is certainly a problem, I find those meetings awfully inefficient
compared to what gets done with mailing lists (eg : linux kernel,
postgresql...). 

But I see another reason : I find a _huge_ part of the workload in
business applications is generated by the demands of the management
local to that organization (hence the meetings). On the other hand,
administrative tasks in general do not change fundamentally very often.

I can imagine a future when we have a few basic open source business
applications that cover 90% of the needs for accounting/CRM/case
management. Most people will just use that, and whoever has special
needs can fork it if it's worth his effort. That would greatly reduce
the need for those meetings.



> The best development
> managers I've seen shield their programmers from those tasks and allow
> them to get work done. There is no agile silver bullet to make
> programmers more effective except giving them uninterrupted time to do
> their jobs.











-- 
Vincent Veyron
http://marica.fr/
Logiciel de gestion des sinistres assurances et des dossiers contentieux pour 
le service juridique



Re: Safe handling of an SQL query

2012-04-17 Thread Vincent Veyron
Le mardi 17 avril 2012 à 20:10 +0200, Michael Ludwig a écrit :
> Bonjour Vincent,
> 
> Vincent Veyron schrieb am 16.04.2012 um 22:21 (+0200):
> > 
> > I guess (in the message I forwarded to the list) Andreas is right,
> > though : the only way to be safe is to keep control of the query,
> > therefore keep it on the server.
> > 
> > I am doing this now, but passing parameters to the query becomes
> > cumbersome :-(
> 
> If you haven't done that already, you could take a look at the following
> three modules. While I have never used any of them I've bookmarked them
> for future opportunities …
> 
> https://metacpan.org/module/SQL::Interp
> https://metacpan.org/module/SQL::Abstract
> https://metacpan.org/module/DBIx::Simple
> 

Guten Tag Michael,

I did not know about those, but what I don't see the benefit compared to
using DBI directly, which is really concise. This is all I need to get a
reference to a data set :

my $dbh = $r->pnotes('dbh_data');

my $sql = 'SELECT ... FROM ... WHERE X=? AND Y=?';

#collect data
eval { $data = $dbh->selectall_arrayref($sql, { Slice => {} },
( $param_x, $param_y ) ) };


where dbh_data is a reference to a dbi connection using connect_cached,
stored in pnotes.

?

-- 
Vincent Veyron
http://marica.fr/
Logiciel de gestion des sinistres assurances et des dossiers contentieux pour 
le service juridique



RE: Safe handling of an SQL query

2012-04-17 Thread eric.berg
Vincent,

Don't make the mistake of thinking that you're not directly using DBI.  

These modules provide an abstraction for creating SQL that is data driven.  
They free you from the error-prone string manipulation process, and allow you 
to build your queries in such a way as to be able to handle a variety of data.

For example, from the SQL::Abstract mod docs:

my $sql = SQL::Abstract->new;
my $table = 'widgets';
my($stmt, @bind) = $sql->select($table, \@fields, \%where, \@order);

Now you can use this for any table selecting any fields with or without 
specifying a where clause or an order by clause.

This allows you to directly create a quick hash to represent your where clause.

So, to get a SQL statement where first_name = 'Sally', last_name starts with 
"S", your %where hash would look like this:

%where = (first_name => 'Sally',
  Last_name => { like => 'S%'});

Which would set the $stmt variable above to 

select * from widgets where first_name = ? and last_name like ?

And the @bind would be

@bind = ('Sally', 'S%')

Very helpful!  Very flexible!  And no more of that messy string manipulation 
and escaping quotes.

Oh, and of course, the next thing you do is:

my $sth = $dbh->prepare($stmt);
$sth->execute(\@bind);

Which is where you directly use DBI.

Most all of this stuff is just an abstraction layer for creating SQL in a 
data-centric way.

> -Original Message-
> From: Vincent Veyron [mailto:vv.li...@wanadoo.fr]
> Sent: Tuesday, April 17, 2012 6:09 PM
> To: Michael Ludwig
> Cc: modperl@perl.apache.org
> Subject: Re: Safe handling of an SQL query
> 
> Le mardi 17 avril 2012 à 20:10 +0200, Michael Ludwig a écrit :
> > Bonjour Vincent,
> >
> > Vincent Veyron schrieb am 16.04.2012 um 22:21 (+0200):
> > >
> > > I guess (in the message I forwarded to the list) Andreas is right,
> > > though : the only way to be safe is to keep control of the query,
> > > therefore keep it on the server.
> > >
> > > I am doing this now, but passing parameters to the query becomes
> > > cumbersome :-(
> >
> > If you haven't done that already, you could take a look at the
> following
> > three modules. While I have never used any of them I've bookmarked
> them
> > for future opportunities …
> >
> > https://metacpan.org/module/SQL::Interp
> > https://metacpan.org/module/SQL::Abstract
> > https://metacpan.org/module/DBIx::Simple
> >
> 
> Guten Tag Michael,
> 
> I did not know about those, but what I don't see the benefit compared
> to
> using DBI directly, which is really concise. This is all I need to get
> a
> reference to a data set :
> 
> my $dbh = $r->pnotes('dbh_data');
> 
> my $sql = 'SELECT ... FROM ... WHERE X=? AND Y=?';
> 
> #collect data
> eval { $data = $dbh->selectall_arrayref($sql, { Slice => {} },
> ( $param_x, $param_y ) ) };
> 
> 
> where dbh_data is a reference to a dbi connection using connect_cached,
> stored in pnotes.
> 
> ?
> 
> --
> Vincent Veyron
> http://marica.fr/
> Logiciel de gestion des sinistres assurances et des dossiers
> contentieux pour le service juridique


___
Barclays is one of the world's leading banks, and we believe that by continuing 
to integrate the organisation we can better deliver the full power of Barclays 
to customers, clients and the communities in which we work. 
As a visible sign of that integration we are moving to a single Barclays brand 
for the majority of our divisions, including those formerly known as Barclays 
Capital, Barclays Wealth and Barclays Corporate.

___

This e-mail may contain information that is confidential, privileged or 
otherwise protected from 
disclosure. If you are not an intended recipient of this e-mail, do not 
duplicate or redistribute 
it by any means. Please delete it and any attachments and notify the sender 
that you have received 
it in error. Unless specifically indicated, this e-mail is not an offer to buy 
or sell or a 
solicitation to buy or sell any securities, investment products or other 
financial product or 
service, an official confirmation of any transaction, or an official statement 
of Barclays. Any 
views or opinions presented are solely those of the author and do not 
necessarily represent those 
of Barclays. This e-mail is subject to terms available at the following link: 
www.barcap.com/emaildisclaimer. 
By messaging with Barclays you consent to the foregoing.  Barclays offers 
premier investment banking 
products and services to its clients through Barclays Bank PLC, a company 
registered in England 
(number 1026167) with its registered office at 1 Churchill Place, London, E14 
5HP.  This email may 
relate to or be sent from other members of the Barclays Group.

___


Re: Safe handling of an SQL query

2012-04-17 Thread Michael Ludwig
Vincent Veyron schrieb am 18.04.2012 um 00:09 (+0200):
> Le mardi 17 avril 2012 à 20:10 +0200, Michael Ludwig a écrit :
> > Vincent Veyron schrieb am 16.04.2012 um 22:21 (+0200):
> > > 
> > > I am doing this now, but passing parameters to the query becomes
> > > cumbersome :-(
> > 
> > https://metacpan.org/module/SQL::Interp
> > https://metacpan.org/module/SQL::Abstract
> > https://metacpan.org/module/DBIx::Simple

> I did not know about those, but what I don't see the benefit compared
> to using DBI directly, which is really concise.

I'm mostly happy using DBI directly, too. The modules I listed do add
a convenience layer on top, though. Which is what I thought you were
looking for; guess I simply got you wrong when you said that passing
parameters was becoming cumbersome. The modules in question strive to
make your life easier. Maybe people can come up with more helpful
suggestions if you post a concrete example of what is cumbersome.

Best,

Michael


Re: Safe handling of an SQL query

2012-04-17 Thread Vincent Veyron
Le mercredi 18 avril 2012 à 00:30 +0200, Michael Ludwig a écrit :
> Vincent Veyron schrieb am 18.04.2012 um 00:09 (+0200):

>  Maybe people can come up with more helpful
> suggestions if you post a concrete example of what is cumbersome.
> 

Sure, the app in my sig has a demo a account which you can use for
that. 

This is an application for the management of insurance claims and legal
cases. Go into any 'Dossier' (French for folder/case) and hit the
'Tiers' tab (French for 'Third Party') at the top of the screen.

There should be at least one person in there, if not you can add one;
click on 'Afficher les modèles' in that person's info.

You'll find two models : one is a Word document (not to open directly in
IE, must be downloaded first and then opened), the other one an
OpenOffice document (which you can open directly).

You'll see that the models auto-fill (merges actually) with data taken
from the database. The data is written to a generic file when you hit
the link, and that file is fetched via a VB procedure on the document's
opening. The query associated with the model is stored on the server and
never sent to the client who only sees the resulting data set.

This works because no additional input is required to fill the models.
But for statistical reports for instance, various inputs from the user
are often required (what year for instance) and there is no place to put
them in my setup. Maintaining a table and a form to manage all sorts of
parameters associated with various reports just seems impractical.

That is the reason I was looking for a way to put the query inside the
report, so that it could be sent with the proper parameters to the
server. That however has other problems, as seen upthread.

-- 
Vincent Veyron
http://marica.fr/
Logiciel de gestion des sinistres assurances et des dossiers contentieux pour 
le service juridique