Home » Logging » Log » Bug #1811

[2004-07-06 20:05 UTC] mjohnson at pitsco dot com

Description:
------------
In some cases it is desirable to be able to set the table used for generating IDs. For instance, I'm logging to a separate database from my primary database but want to share the connection. Therefore, I have to specify the DB in the table name.

The patch in the reproduce code section allows the id table to be specified in the idTable config value. It defaults to log_id, the same as the current code.

My creation code now looks like:
$logger =& Log::singleton('sql', 'x.log_table', 'xyz',
array('db' =& $db,
'idTable' = 'x.log_id'));

Thanks,
Michael

Reproduce code:
---------------
64a65,71
>
> /**
> * String holding the database table to store the log id in.
> * @var string
> * @access private
> */
> var $_idTable = 'log_id';
82a90,94
>
> // Set the log ID table
> if (isset($conf['idTable'])) {
> $this->_idTable = $conf['idTable'];
> }
166c178
< $id = $this->_db->nextId('log_id');
---
> $id = $this->_db->nextId($this->_idTable);

[2004-07-12 14:24 UTC] mjohnson at pitsco dot com

I believe that will handle my situation.

However, I'm unsure about the arbitrary 56 in the substr though. I'm guessing it's to ensure the resulting table name is not too long. However, there is the extreme case where the database name is at its maximum and the table name is at its maximum, resulting in an identifier that is only the database name, which would then fail. It could also result in strange or even overlapping table names if the database name is long enough to cause the table name to be truncated to a very short name.

In my eyes, just allowing the id table to be specified takes care of all these problems. Leave a resonable default (perhaps this latest change?), but give the user an out. The reason I say this is that, in my experience, there's always a case you didn't consider. Making it user configurable allows for those cases and simplifies or removes specialized code from a generic class.

Thanks,
Michael