| Package home | Report new bug | New search | Development Roadmap | Status: Open | Feedback | All | Closed Since Version 1.11.5 |
| Bug #5484 | dispensing with class_prefix leads to segmentation fault | ||
|---|---|---|---|
| Submitted: | 2005-09-22 03:30 UTC | ||
| From: | roger at ecstatic dot com | Assigned: | alan_k |
| Status: | Suspended | Package: | DB_DataObject |
| PHP Version: | 4.3.11 | OS: | |
| Roadmaps: | (Not assigned) | ||
[2005-09-22 03:30 UTC] roger at ecstatic dot com
Description:
------------
I want my persistent classes to have the same names as
the underlying tables, so I set 'class_prefix' to the
empty string. This works great...except that I happen
to have a table called 'Factory'. Calling
DB_DataObject::Factory() with an argument of 'Factory'
causes a segmentation fault. :-(
In the discussion for bug #3256, I see a reference to
this being a design decision. Fair enough; I'll report
this as a documentation bug. I've reported it here,
though, in case it affects the implementation of any
changes, such as those being discussed in #3256.
Test script:
---------------
<?php
require_once 'PEAR.php';
require_once 'DB/DataObject.php';
$options = &PEAR::getStaticProperty('DB_DataObject','options');
$options = array(
'database' => 'mysql://user:password@localhost/vending',
'schema_location' => '/home/me/Projects/myapplication/DataObjects',
'class_location' => '/home/me/Projects/myapplication/DataObjects',
'require_prefix' => 'DataObjects/',
'class_prefix' => '',
);
$obj = DB_DataObject::Factory('Factory');
?>
Expected result:
----------------
Nothing.
Actual result:
--------------
A long pause, then a Segmentation fault.
Comments
[2005-10-25 03:15 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2005-11-06 09:41 UTC] roger at ecstatic dot com
I'm not in a position to use the latest code on my
project--my client stipulates that I use a stable,
released version of the package. I just stuck a prefix
on and went about my work.
[2005-11-07 01:54 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!