Your problem is that the column named 'id' isn't the id column! If it was the Perl accessor would return the same, correct value.

Instead you have a multi-col pk where one column of it is misleading named id, so I'd rename the column, not only its Perl accessor.

Best regards, Alex


On 2017-11-29 12:39, Vladimir Melnik wrote:
Thank you!

That's why I can't decide should I rename the `id` column to `_id` or should I 
only change the 1st parameter of the `add_columns()` call from `id` to `_id`. 
Or should I make my own method (and call it, let's say, `PKs`) to do the same 
thing that `DBIx::Class::PK::id` does?

It's always difficult to decide what way is better when all ways are "correct". 
:-)

Being grateful for all your comments and suggestions regarding this topic,
Vlad

On Tue, Nov 28, 2017 at 01:46:17PM +0100, Hartmaier Alexander wrote:
Hi,

when you define your 'id' column using add_column it generates an
accessor method named 'id' which overwrites the id method of
DBIx::Class::PK.

Best regards, Alex


On 2017-11-28 10:56, Vladimir Melnik wrote:
Dear colleagues,

Is `id()` should return a content of the `id` column if it presents, even if we 
have a multi-column PK (so it's supposed to return a list of PK values as it 
described in the `DBIx::Class::Row` manual)?

So, I have a table whose PKs are `id` and `known_from`, I have the following in 
the Result-based class definition:

     __PACKAGE__->set_primary_key("id", "known_from");

But it always return one number - the content of the `id` column.

What overrides what: an internal method and a column-name-based method? If the 
column-name-based one has higher priority, should I consider renaming the `id` field to some 
crappy `_id`? Or would it be a better way to call it as '_id' when I'm doing 
`__PACKAGE__->add_columns("id", ...)`? If yes, would it be possible to ask 
`DBIx::Class::Schema::Loader` to do that each time?

Thanks in advance for your time, dear colleagues.

If anyone have experince with multi-column PK with DBIx::Class and with 
temporal (also as bi-temporal and multi-temporal) - please share your wisdom.



*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
T-Systems Austria GesmbH Rennweg 97-99, 1030 Wien
Handelsgericht Wien, FN 79340b
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*
Notice: This e-mail contains information that is confidential and may be 
privileged.
If you are not the intended recipient, please notify the sender and then
delete this e-mail immediately.
*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*"*

_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk


_______________________________________________
List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class
IRC: irc.perl.org#dbix-class
SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/
Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk

Reply via email to