On Jan 11, 2007, at 3:54 PM, John Siracusa wrote:
>
> If so, let's go with "Debug" instead of "Debugging". I picked
> "Debugging"
> before because I didn't want any confusion with the various $Debug
> package
> variables, but if everything's going to be in ::Debug::*, then
> that's not an
>
On 1/11/07 3:49 PM, Jonathan Vanasco wrote:
> i'm going to structure it like this:
>
> Rose::DB::Object::Debugging base namespace (empty)
> Rose::DB::Object::Debugging::Helpers mixin objects for debugging
If so, let's go with "Debug" instead of "Debugging". I picked "Debugging"
before beca
On Jan 11, 2007, at 3:13 PM, John Siracusa wrote:
> Helpers are pretty wide-open, so don't ask, just write it :) If it
> really
> is solely for debugging, however, I think a
> Rose::DB::Object::Debugging
> module would a nice. It'd be the same thing as Helpers (import
> methods
> under op
On 1/11/07 3:04 PM, Jonathan Vanasco wrote:
> first off- i'd be willing to write this one.
Helpers are pretty wide-open, so don't ask, just write it :) If it really
is solely for debugging, however, I think a Rose::DB::Object::Debugging
module would a nice. It'd be the same thing as Helpers (imp
first off- i'd be willing to write this one.
i'd like to see something like this for debugging:
$rodbObject->status();
that outputs:
===
This object IS in synch with the last known DB version | This
object IS NOT in synch with the last DB version
fieldname | object_value |
On 1/11/07 2:16 PM, Jonathan Vanasco wrote:
> On Jan 11, 2007, at 2:03 PM, John Siracusa wrote:
>> I believe this is a DBI/DBD::Pg/libpg issue/reality/"feature" :) If you
>> use DBI's prepare_cache() method and you change the db schema between calls,
>> the previously-cached version of the cach
On Jan 11, 2007, at 2:03 PM, John Siracusa wrote:
> I believe this is a DBI/DBD::Pg/libpg issue/reality/"feature" :)
> If you
> use DBI's prepare_cache() method and you change the db schema
> between calls,
> the previously-cached version of the cached statement will become
> invalid.
> I
On 1/11/07 1:39 PM, Jonathan Vanasco wrote:
> if i change a table columns definition during testing, I'll get
> these errors:
>
> DBD::Pg::st execute failed: ERROR: prepared statement "dbdpg_17"
> does not exist
I believe this is a DBI/DBD::Pg/libpg issue/reality/"feature" :) If you
use DBI's
Runnin ModPerl2 w/ Apache Restart + Apache DBI + Postgres, I found this:
if i change a table columns definition during testing, I'll get
these errors:
DBD::Pg::st execute failed: ERROR: prepared statement
"dbdpg_17"
does not exist
and to note, on every cha