Re: Class::DBI ponderings

[Tony Bowden]

On Fri, Feb 07, 2003 at 08:00:07PM +, Shevek wrote:
> On reading the code, this is sufficient. Don't call set_db at all. This is 
> pretty close to the architecture I used to use: Each class was responsible 
> for providing an appropriate DB handle on demand. If you don't call 
> set_db, and just use connect_cached, then much of what followed in Tony's 
> mail may be simplified.

yes, this is indeed true. I hadn't actually thought of that.

I need to put together a good write-up on all the different approaches
to this.

Tony

Re: Class::DBI ponderings

[Shevek]

On Fri, 7 Feb 2003, Tony Bowden wrote:

> On Fri, Feb 07, 2003 at 05:34:39PM +, Simon Batistoni wrote:
> > 2) If people do connect with different users dependent on task, how do
> > you keep your cached DB handles straight? I'd thought of subclassing
> > admin-related tasks into separate packages, so that they always get an
> > Object::Foo::Admin-created DB handle, but this seems unwieldy in the
> > extreme.
> 
> In your main Class::DBI subclass, which will presumably be the
> superclass for each of your 'table' classes, you can override the
> db_Main method.

On reading the code, this is sufficient. Don't call set_db at all. This is 
pretty close to the architecture I used to use: Each class was responsible 
for providing an appropriate DB handle on demand. If you don't call 
set_db, and just use connect_cached, then much of what followed in Tony's 
mail may be simplified.

S.

-- 
Shevek
I am the Borg.

sub AUTOLOAD{my$i=$AUTOLOAD;my$x=shift;$i=~s/^.*://;print"$x\n";eval
qq{*$AUTOLOAD=sub{my\$x=shift;return unless \$x%$i;&{$x}(\$x);};};}

foreach my $i (3..65535) { &{'2'}($i); }

Re: Class::DBI ponderings

[Tony Bowden]

On Fri, Feb 07, 2003 at 05:34:39PM +, Simon Batistoni wrote:
> What do other people do? Just connect using a user with full
> privileges, regardless of the script's task? I can't see huge security
> disadvantages in this, particularly as such users are locked down to
> only take connections from localhost. Still, opinions would be nice.

This is what we generally do ... but if you want to keep the two users:

> 2) If people do connect with different users dependent on task, how do
> you keep your cached DB handles straight? I'd thought of subclassing
> admin-related tasks into separate packages, so that they always get an
> Object::Foo::Admin-created DB handle, but this seems unwieldy in the
> extreme.

In your main Class::DBI subclass, which will presumably be the
superclass for each of your 'table' classes, you can override the
db_Main method.

Unfortunately, because of the way Ima::DBI just throws this method into
your namespace, you can't do this directly.

You can create another level of subclassing so that you can properly
override the method:


package My::DBI::Base;

use base 'Class::DBI';
__PACKAGE__->set_db();

package My::DBI;

use base My::DBI::Base;

sub db_Main {
my $class = shift;
if ($class->different_privs) {
return Ima::DBI->connect_cached('other connect string');
} 
return $class->SUPER::db_Main;
}

1;

Or, you can grab a copy of the method after it's been created, and mess
about with it:


package My::DBI;

use base 'Class::DBI';
__PACKAGE__->set_db();

{
no warnings 'redefine';
*db_Orig = \&db_Main;
*db_Mail = sub {
my $class = shift;
if ($class->different_privs) {
return Ima::DBI->connect_cached('other connect 
string');
} 
$class->db_Orig;
}
}


It's kinda tricky, and should really be a lot nicer, but it's fairly
flexible (we've used it to have lots of different databases with the
same schema, and the correct one gets picked depending on certain
circumstances (what user you're logged in as, which vhost you're using, 
what the path name is, whatever)...

If you've any more questions, the Class::DBI mailing list has a few
people who've done things like this.

Thanks,

Tony

Re: Class::DBI ponderings

[Simon Wilcox]

On Fri, 2003-02-07 at 17:34, Simon Batistoni wrote:
> We're currently considering shifting our core mod-perl system here at
> work to use Class::DBI, since many of the classes we have already are
> pretty much reinventing its wheel, and we currently have the time and
> space to make a few structural changes before the next development
> onslaught begins.
> 
> However, I've run up against an interesting little problem. Currently,
> our database (mysql) has two users for cgi access - one called
> "nobody", which has read-access only to the database, and one called,
> well, never you mind, which has full access.
> 
> Scripts that are just dealing with front-end presentation use the
> "nobody" user, whilst the CMS side of the system uses the full-access
> user.
> 
> The problem with Class::DBI is that its connections persist across
> classes, and since we want to do as much caching of DB connections etc
> as possible, the scheme of having two database users gets a bit
> tricky.
> 
> So, two major questions:
> 
> 1) The old "nobody"/full-access duality is an old piece of history,
> and rose out of the general principle that it's best to only have a
> full-access user connected when necessary. However, it came about when
> there was very little caching in the system, and has now become a
> pain where once it wasn't.
> 
> What do other people do? Just connect using a user with full
> privileges, regardless of the script's task? I can't see huge security
> disadvantages in this, particularly as such users are locked down to
> only take connections from localhost. Still, opinions would be nice.
> 
> 2) If people do connect with different users dependent on task, how do
> you keep your cached DB handles straight? I'd thought of subclassing
> admin-related tasks into separate packages, so that they always get an
> Object::Foo::Admin-created DB handle, but this seems unwieldy in the
> extreme.
> 
> 
> Unless anyone can convince me that it's a bad idea, I think having a
> single "full access" user is going to be the most attractive solution
> here, but opinions welcome.

I tend to use a single user with read/write access and do the security
at the application level. They still don't have "full" access, just
enough to do what they need to do.

Assuming you have subclassed Class::DBI and then subclassed again for
each of your objects (the recommended way) then you can overload db_Main
to return the right handle.

Basically db_Main is called every time Class::DBI needs a database
connection. I overload it so that I can establish the connection
dynamically at run time from a config file but there is no reason why
you can't have it look at some variable (e.g. the users id or the
attempted action) and return a read only or read/write connection.

HTH,

Simon.

Class::DBI ponderings

[Simon Batistoni]

We're currently considering shifting our core mod-perl system here at
work to use Class::DBI, since many of the classes we have already are
pretty much reinventing its wheel, and we currently have the time and
space to make a few structural changes before the next development
onslaught begins.

However, I've run up against an interesting little problem. Currently,
our database (mysql) has two users for cgi access - one called
"nobody", which has read-access only to the database, and one called,
well, never you mind, which has full access.

Scripts that are just dealing with front-end presentation use the
"nobody" user, whilst the CMS side of the system uses the full-access
user.

The problem with Class::DBI is that its connections persist across
classes, and since we want to do as much caching of DB connections etc
as possible, the scheme of having two database users gets a bit
tricky.

So, two major questions:

1) The old "nobody"/full-access duality is an old piece of history,
and rose out of the general principle that it's best to only have a
full-access user connected when necessary. However, it came about when
there was very little caching in the system, and has now become a
pain where once it wasn't.

What do other people do? Just connect using a user with full
privileges, regardless of the script's task? I can't see huge security
disadvantages in this, particularly as such users are locked down to
only take connections from localhost. Still, opinions would be nice.

2) If people do connect with different users dependent on task, how do
you keep your cached DB handles straight? I'd thought of subclassing
admin-related tasks into separate packages, so that they always get an
Object::Foo::Admin-created DB handle, but this seems unwieldy in the
extreme.


Unless anyone can convince me that it's a bad idea, I think having a
single "full access" user is going to be the most attractive solution
here, but opinions welcome.

Re: xs & c++?

[Graham Seaman]

On Fri, 7 Feb 2003, Joel Bernstein wrote:

> On Fri, Feb 07, 2003 at 11:55:18AM +, Graham Seaman wrote:
> > Hi,
> > 
> > I'm trying to do a perl wrapper for a c++ library and I'm floundering -
> > I have v. little experience of xs. Can anyone point me to a module
> > that is a good example of how to do this, without being too huge?
> > (I'm aware of the cookbook, but am looking for more of a real-life
> > example...)
> 
> Inline::C++ might be a better way to do this?

Thanks, I didn't know about that - looks like it should simplify things
considerably :-)

Graham

Re: Anyone for a pub meet? South of the Thames?

[Phil Pereira]

Well,

It'll be th etwo of us; unless you come along! You're, obviously, very welcome to - as 
well as anyone else!

Will you be able to? Hope so - the more the merrier!

On Fri, 7 Feb 2003 00:54:36 +
"Natalie S. Ford" <[EMAIL PROTECTED]> wrote:

> On Mon, Feb 03, 2003 at 09:16:07PM +, David Cantrell wrote:
> > On Mon, Feb 03, 2003 at 08:42:03PM +, Phil Pereira wrote:
> > > David Cantrell <[EMAIL PROTECTED]> wrote:
> > > > Slightly more seriously - how about the Dog n Bull on Surrey St?
> > > Just to confirm, this is the pub location:
> > > http://www.multimap.com/map/browse.cgi?client=&pc=CR01RG
> > Yup.
> > > I'm pre-booked for next Monday, however, Thursday (13th Feb) is good with me! 
>Just say the time and I'll meet you there ... as well as anyone else who'd like to 
>come  :)
> > 6pm onwards.
> 
> So, is it just going to be the two of you?  I may be able to make it
> - Croydon is a bit easier than London for me...
> 
> -- 
> Natalie S. Ford   .   [EMAIL PROTECTED]
> .  http://www.natalie.ourshack.org
> 
> 


-- 
Phil.
---
   (_ )
UNIX is "user-friendly",\\\", ) ^
it's just picky about its friends!\/, \(
 cXc_/_)
---

Re: xs & c++?

[Dominic Mitchell]

Graham Seaman wrote:

Hi,

I'm trying to do a perl wrapper for a c++ library and I'm floundering -
I have v. little experience of xs. Can anyone point me to a module
that is a good example of how to do this, without being too huge?
(I'm aware of the cookbook, but am looking for more of a real-life
example...)


If you can spend money, there's been a book recently released on perl 
and XS.  I'm not sure how much C++ it covers though.



You may also wish to look at SWIG instead of XS.  It provides an 
alternative way of doing similiar things, which some people find easier 
to deal with.  Development on it seems to have picked up again in the 
last year, it seems to be getting better, particularly with regards to C++.



As the above book review notes, "Embedding and Extending Perl" also 
contains a section on SWIG, although its main foxus is XS.

-Dom

--
| Semantico: creators of major online resources  |
|   URL: http://www.semantico.com/   |
|   Tel: +44 (1273) 72   |
|   Address: 33 Bond St., Brighton, Sussex, BN1 1RD, UK. |

Re: xs & c++?

[Joel Bernstein]

On Fri, Feb 07, 2003 at 11:55:18AM +, Graham Seaman wrote:
> Hi,
> 
> I'm trying to do a perl wrapper for a c++ library and I'm floundering -
> I have v. little experience of xs. Can anyone point me to a module
> that is a good example of how to do this, without being too huge?
> (I'm aware of the cookbook, but am looking for more of a real-life
> example...)

Inline::C++ might be a better way to do this?
Otherwise, http://www.johnkeiser.com/perl-xs-c++.html might be enough
info for you to manage XS and C++ together.

/joel

xs & c++?

[Graham Seaman]

Hi,

I'm trying to do a perl wrapper for a c++ library and I'm floundering -
I have v. little experience of xs. Can anyone point me to a module
that is a good example of how to do this, without being too huge?
(I'm aware of the cookbook, but am looking for more of a real-life
example...)

thanks
Graham

Re: CPANSTATS

[Peter Haworth]

On Fri, 7 Feb 2003 09:22:16 +0100, Newton, Philip wrote:
> And /PNE/s/Phillip/Philip/ (excuse my sed there), please.

Don't forget s/Damien Conway/Damian Conway/

-- 
Peter Haworth   [EMAIL PROTECTED]
"...the word HACK is used as a verb
 to indicate a massive amount of nerd-like effort."
-- Harley Hahn, A Student's Guide to UNIX

Re: CPANSTATS

[Simon Wistow]

On Thu, Feb 06, 2003 at 08:09:49PM +, Adam Spiers said:
> Hey, I think you're missing an
> 
> ASPIERS   => "Adam Spiers",
> 
> in that ;-)

Duly updated and freshly alphabetized (more or less).

Anybody else?

Re: CPANSTATS

[Newton, Philip]

Adam Spiers wrote:
> 
> Simon Wistow ([EMAIL PROTECTED]) wrote:
> > 
> > http://thegestalt.org/simon/perl/cpanscore.html
> 
> Hey, I think you're missing an
> 
> ASPIERS   => "Adam Spiers",
> 
> in that ;-)

And /PNE/s/Phillip/Philip/ (excuse my sed there), please.

Cheers,
Philip
-- 
Philip Newton <[EMAIL PROTECTED]>
All opinions are my own, not my employer's.
If you're not part of the solution, you're part of the precipitate.