RE: Reblessing question: change primary key name?

[prev] [thread] [next] [Date index for 2005/01/10]

>> Is there a way to rename the column name, its accessor and mutator?

>This stuff happens at compile time.  It seems like re-blessing would do
>what you want though.  What's going wrong?

I guess what happens is fairly logical - both columns are there, the new
one is 'Primary' (the old one is still in 'Essential'), the new one is
undef and the old one has the id.

So:

bless( {
	'name' =3D> 'new_primary_key',
	'_groups' =3D> {
		'Essential' =3D> 1,
		'Primary' =3D> 1
	},
	'mutator' =3D> 'new_primary_key',
	'placeholder' =3D> '?',
	'accessor' =3D> 'new_primary_key'
}, 'Class::DBI::Column' ),
bless( {
	'_groups' =3D> {
		'Essential' =3D> 1
	},
	'name' =3D> 'old_primary_key',
	'mutator' =3D> 'old_primary_key',
	'placeholder' =3D> '?',
	'accessor' =3D> 'old_primary_key'
}, 'Class::DBI::Column' ),

I tried manually assigning the value and yanking the old one out of
'Essential' (setting '_groups' =3D> {} seemed like it would do the =
trick),
but bad things kept happening.  Thought I'd try to find out what the
Right Thing to do is, before breaking things.

>> Another approach I am thinking of is to ->construct() the new object=20
>> I
>> want from scratch, but this requires overloading the constructors and

>> I'd much rather do the reblessing from a 'select' trigger (seems like

>> it'd be faster, too).

>I'm not sure why it would involve overloading.  You can just grab the
>data from one object and construct() another of a different class from
it.

I meant the place where I do this construct: I want the
reblessing/reconstructing to happen automatically (so, retrieve from
Foo, get a Foo::Bar), right now I define a 'select' trigger and the
blessing happens automagically; on the other hand there are so many ways
for C:DBI objects to get created that I am not sure where the right
place to interfere with that process is.

>Also, have you looked at Class::DBI::Relationship::IsA?

I prefer to do the data munging part of the Class Inheritance <->
Relational Tables transition (debacle?) at the database level: it's a
nice, clean abstraction, gives me a very easy way in for update
tracking, audit logging and handling various special cases; faster too
(single select on a view of a join, vs one select for the 'base' class
and an additional one - or more - for each record, and easier on memory
(for large numbers of records).

Thanks for your help!

Dmitri