[EMAIL PROTECTED] (Jeffrey W. Baker) wrote:
>I've worked with Scott Ambler, and I could record everything Scott Ambler
>knows about actually devleloping large systems on the head of a pin, using
>a magic marker. That guy is a hopeless academic without the slightest
>clue of how to actually make s
On Thu, 2 Aug 2001, Tim Bunce wrote:
> I think DBIx::AnyDBD is a pretty good compromise.
Well, I worked with Matt on the project for which it was developed
(WebBoard for Unix) and I still felt like there was just way too much
stuff to deal with. Just too much SQL. I wanted a more abstract way
On Wed, Aug 01, 2001 at 05:29:10AM -0700, Daniel wrote:
> Nicely put Nick. There's already a Structured Query Language,
> And there's an easy to use abstraction called DBI up on CPAN.
> Feel free to use in application code thusly:
>
> my $statement = qq~
> SELECT field1, field2
> F
On Wed, Aug 01, 2001 at 01:19:58PM -0500, Dave Rolsky wrote:
> On Wed, 1 Aug 2001, Kyle Dawkins wrote:
>
> > I've taken a look at many of them (Tangram? a few others) and haven't been
> > impressed with any of them. I think part of the problem is that they're all
> > being developed in a bit of
Nicely put Nick. There's already a Structured Query Language,
And there's an easy to use abstraction called DBI up on CPAN.
Feel free to use in application code thusly:
my $statement = qq~
SELECT field1, field2
FROM table
WHERE id = ?
~;
my $ref;
my $sth = $dbh->prepa
At 02:44 PM 8/1/2001 -0700, Jeffrey W. Baker wrote:
>On Thu, 2 Aug 2001, Gunther Birznieks wrote:
>
> > When you've had your fill of wrestling over mySQL vs PostGres and stored
> > procs versus inline SQL (I know I have long ago)
> >
> > You guys should definitely read the following:
> >
> >
Yeah!
Go Gunther. This is one of the better articles on persistence... Scott
Ambler has tons of good stuff on his site and I highly recommend it as a
source for finding out about interesting techniques. What he describes
is quite similar to the EOF link I put in one of my earlier posts.
> Y
on is the right one or not.
--Joe Breeden
--
Sent from my Outlook 2000 Wired Deskheld (www.microsoft.com)
> -Original Message-
> From: Nick Tonkin [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, August 01, 2001 4:15 PM
> To: Joe Breeden
> Cc: [EMAIL PROTEC
Since you asked, my opinion is that what you describe would not be
useful. Primarily for the reason pointed out already by a number of people
-- lack of flexibility. Most, if not all, database servers accept highly
customizable performance params to a query, and most even moderately
evolved appl
On 01 Aug 2001 14:29:10 -0400, Perrin Harkins wrote:
> > http://axkit.org/docs/presentations/tpc2001/anydbd.axp
>
> Is this basically a hash of SQL statements, indexed by DBD type? Or is
> there something more that I'm missing? (I should have gone to your TPC
> talk...)
All AnyDBD does is crea
> Cc: [EMAIL PROTECTED]
> Subject: Re: [OT] Inspired by closing comments from the UBB thread.
>
>
> > http://axkit.org/docs/presentations/tpc2001/anydbd.axp
>
> Is this basically a hash of SQL statements, indexed by DBD
> type? Or is
> there something more that I'
> http://axkit.org/docs/presentations/tpc2001/anydbd.axp
Is this basically a hash of SQL statements, indexed by DBD type? Or is
there something more that I'm missing? (I should have gone to your TPC
talk...)
> As for SQL, I just wish people would expand their horizons a little
> and start doing a bit of reading. There are so many different ways
> to avoid embedding SQL in application code and I sincerely wish
> programmers would THINK before just coding... it's what
> differentiates scripters from en
On Wed, 1 Aug 2001, Kyle Dawkins wrote:
> I've taken a look at many of them (Tangram? a few others) and haven't been
> impressed with any of them. I think part of the problem is that they're all
> being developed in a bit of a vacuum. But let's capitalise on the interest
> that this thread has
On Wed, 1 Aug 2001, Ray Zimmerman wrote:
> One of the tools that is not mentioned in Dave's write-up (probably
> because it didn't exist then) is SPOPS, mentioned earlier in this
> thread.
No, I just hadn't had a chance to get around to it yet. I really need to
finish that thing someday. Of co
> Jay Jacobs wrote:
> >
> > I don't see any glue-sniffing symptoms from choosing
> > embedded html in perl over embedded perl in html.
> >
>
> Unless, of course, you're the graphic artist and you've been tasked
> with changing the look and feel of the application using embedded
> perl (which you,
On 01 Aug 2001 10:12:45 -0500, Joe Breeden wrote:
> All,
>
> In his closing comments about UBB Kyle Dawkins made a statement that got me
> wondering. He said "there's SQL embedded all throughout the Perl everywhere
> (who does this?! oh my god, are they on crack?)". This comment got me
> wonderin
Woooie!?!
I didn't expect the firestorm this post would generate. From what I hear
people are either embedding SQL or writing their own utility module to
essentially do something along the line of:
$s->StartDBI ( DSN => 'somedsn_pointer') ;
eval {
$s->SelectSQL ( NAME => 'sql_select',
At 12:50 PM -0400 8/1/01, Perrin Harkins wrote:
>It would really be nice if someone could write an overview of the O/R
>mapping tools for Perl. I know Dave Rolsky was working on one, but it's a
>big job and he's busy with Mason.
I agree. There was a bit of discussion on this topic on this list
All (and Perrin)
> > If you wish to see one enlightened approach, please read this:
> >
>
http://developer.apple.com/techpubs/webobjects/DiscoveringWO/EOFArchitecture
> > /index.html
as I said... *ONE* enlightened approach :-)
I think you'd find that EOF (the persistence framework in that exampl
> As for SQL, I just wish people would expand their horizons a little and
> start doing a bit of reading. There are so many different ways to avoid
> embedding SQL in application code and I sincerely wish programmers would
> THINK before just coding... it's what differentiates scripters from
> en
Guys guys guys
Mixing HTML with Perl with SQL is bad and evil on every single possible
level. For those who don't know how to split apart your perl from your HTML
I suggest you read some of Perrin's recent posts. There are so many ways to
do it, I won't even bother with talking about them here.
Jay Jacobs wrote:
>
> I don't see any glue-sniffing symptoms from choosing
> embedded html in perl over embedded perl in html.
>
Unless, of course, you're the graphic artist and you've been tasked with
changing the look and
feel of the application using embedded perl (which you, as the graphics
I wasn't clear enough... My point was more "six one way, half dozen the
other". For a public package, keeping dependancies down to a minimum is a
bonus, as well as keeping performance up by not having to pre-process html
looking for perl code. It can come down to a choice between
maintainability
> "not to mention the HTML embedded all throughout the perl (are they on
> glue?)"
>
> What's the alternative there? Embed perl in the HTML?
You could do that (Text::Template), or you could use a tool like Template
Toolkit or HTML::Template. See
http://perl.apache.org/features/tmpl-cmp.html for
I'd second the original question, I've always embedded the SQL (what's the
"S" for?) in the code, isn't that the point of the wonderful DBD::*
packages? As far as modularizing database calls, there are a couple
reasons I've had problems with that. I found the methods being rewritten
to handle a
* Joe Breeden ([EMAIL PROTECTED]) [010801 10:25]:
> All,
>
> In his closing comments about UBB Kyle Dawkins made a statement that got me
> wondering. He said "there's SQL embedded all throughout the Perl everywhere
> (who does this?! oh my god, are they on crack?)". This comment got me
> wonderin
> I think a lot of people's approach, including mine, is to have OO Perl
> modules for all database access. In my code (I use Mason), a web page
> only gets its data through calls like this:
>
> my $obj = NAIC::User->(DBH=>$dbh, EMAIL=>'[EMAIL PROTECTED]');
> $obj->load;
> my $groups_list = $obj-
>All,
>
>In his closing comments about UBB Kyle Dawkins made a statement that got me
>wondering. He said "there's SQL embedded all throughout the Perl everywhere
>(who does this?! oh my god, are they on crack?)". This comment got me
>wondering about alternatives to embedding SQL in to the code of
Joe Breeden [mailto:[EMAIL PROTECTED]] wrote:
...
> wondering about alternatives to embedding SQL in to the code
> of a program.
...
> It would be interesting to know how other people have solved
> that problem.
One approach is to use something like Ima::DBI, which I'm currently toying
with.
I think a lot of people's approach, including mine, is to have OO Perl
modules for all database access. In my code (I use Mason), a web page
only gets its data through calls like this:
my $obj = NAIC::User->(DBH=>$dbh, EMAIL=>'[EMAIL PROTECTED]');
$obj->load;
my $groups_list = $obj->groups();
T
31 matches
Mail list logo