Re: Sharing a database handle among objects

I don't currently see the need for separate Vhost::Location objects -- the Vhost objects already have the ability to enumerate the locations they're tracking.

That indicates to me that there's already some data structure within the Vhost object that knows which locations need to be tracked. Unless there's some very compelling reason that the Locations have to be separate objects, I'd keep them as member data of the Vhost objects.

My mental image of your database schema is that you have one table for each Vhost, with location, hits, and perhaps modification time columns. If it's normalized, you might have a hosts table with a host_id, and a locations table as described before, but with a host_id which can be used to join on the hosts table.

In either case, I haven't fully answered your question yet.

I would definitely pass $dbh to the Vhost constructor. When it comes time to perform a database operation, check the definedness of it and create a new database handle if necessary.

Unless you're writing a multithreaded program, or are getting database handles from a pool (as one would expect with Apache::DBI), you won't see concurrent access on the same handle and things should work just fine.

Comment on Re: Sharing a database handle among objects

Replies are listed 'Best First'.
RE: Re: Sharing a database handle among objects by arturo (Vicar) on Oct 03, 2000 at 22:29 UTC
My mental image of your database schema is that you have one table for each Vhost, with location, hits, and perhaps modification time columns. If it's normalized, you might have a hosts table with a host_id, and a locations table as described before, but with a host_id which can be used to join on the hosts table. Actually, the schema is one table for vhosts, one for locations, and one for hits. The location table has a vhost_id column (as a foreign key) and the hit table has a location ID linked as a foreign key. Additionally, although I'm not sure of the wisdom of this move, since locations can nest, I have a 'parent id' linked as a foreign key within the location table (i.e. a location can have a 'parent' ... this way I can keep track of hits to a directory that aren't hits to the particular file). All this is supposed to be user-configurable (the various admins of the various virtual hosts can set up which locations they want reporting on) If this brings to mind any further ideas about design, etc. I'd love to hear it. Thanks to all who've replied so far! Philosophy can be made out of anything -- or less	[reply]

Replies are listed 'Best First'.

RE: Re: Sharing a database handle among objects
by arturo (Vicar) on Oct 03, 2000 at 22:29 UTC

My mental image of your database schema is that you have one table for each Vhost, with location, hits, and perhaps modification time columns. If it's normalized, you might have a hosts table with a host_id, and a locations table as described before, but with a host_id which can be used to join on the hosts table.

Actually, the schema is one table for vhosts, one for locations, and one for hits.

The location table has a vhost_id column (as a foreign key) and the hit table has a location ID linked as a foreign key.

Additionally, although I'm not sure of the wisdom of this move, since locations can nest, I have a 'parent id' linked as a foreign key within the location table (i.e. a location can have a 'parent' ... this way I can keep track of hits to a directory that aren't hits to the particular file).

All this is supposed to be user-configurable (the various admins of the various virtual hosts can set up which locations they want reporting on)

If this brings to mind any further ideas about design, etc. I'd love to hear it.

Thanks to all who've replied so far!

Philosophy can be made out of anything -- or less

[reply]