Skip Menu |
 

This queue is for tickets about the DBIx-Class CPAN distribution.

Report information
The Basics
Id: 120089
Status: open
Priority: 0/
Queue: DBIx-Class

People
Owner: Nobody in particular
Requestors: mmcgillis [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 0.03
Fixed in: (no value)



Subject: DBIx::Class::InflateColumn option for passing scalers through
Download (untitled) / with headers
text/plain 1.1k
See bug: https://rt.cpan.org/Ticket/Display.html?id=119985 For driver of this bug. In the above bug InflateColumn is never passing the scaler value through to Serializer for it to properly format its value which is expected behavior as documented in the InflateColumn code when writing to the database. However this ends up with invalid JSON data in field that is suppose to be JSON so when reading the data the JSON parser rejects it. Now the Serializer JSON module could deal with this as a special case and probably skip the JSON parsing when this is detected but then anything else that might use the database directly expecting the field has real JSON content would still either blow up or also require special processing. The better answer to me is to get proper JSON values in the database. To accomplish this requires that the InflateColumn default mode of dealing with scalers needs to have some option or setting that can enable/disable it. So normally it does what it currently does but if a sub module sets "passscalers" to true say then InflateColumn would then pass those values as well for processing. This way any module that needs to also process scalar values for correct storage in the database can.
Download (untitled) / with headers
text/plain 635b
After additional tracing of code it looks like this problem is even farther up stream than the InflateColumn. In DBIx::Class::Row new we have: ... foreach my $key (keys %$attrs) { if (ref $attrs->{$key} and ! is_literal_value($attrs->{$key}) ) { .... } $new->store_column($key => $attrs->{$key}); } ... In the above code for a new row anytime we have something that passes "is_literal_value" it will get dumped into the database as is. So this code would also require modification in order to support any sort of configurable notion of passing scalers through to InflateColumn. Could be other places as well.
Download (untitled) / with headers
text/plain 109b
actually is_literal_value in this case doesn't matter "ref $attrs->{$key}" for a scalar will always be false.
Download (untitled) / with headers
text/plain 845b
On Sat Feb 04 00:57:35 2017, MMCGILLIS wrote: Show quoted text
> To accomplish this requires that the InflateColumn default mode of > dealing with scalers needs to have some option or setting that can > enable/disable it. So normally it does what it currently does but if a > sub module sets "passscalers" to true say then InflateColumn would > then pass those values as well for processing. This way any module > that needs to also process scalar values for correct storage in the > database can.
The DBIx::Class::FilterColumn module does *exactly* what you describe above. Giving a modifiable behavior to ::InflateColumn is difficult if not impossible, as it is a part of the relationship mechanism as well. I will keep this ticket open for some months to remind myself to check back on you. Let me know if ::FilterColumn would work for you going forward.
Download (untitled) / with headers
text/plain 294b
Well if that is the case then the author of DBIx::Class::InflateColumn::Serializer would need to probably change the module to DBIx::Class::FilterColumn::Serializer if that is the case. Not sure that will solve bug: https://rt.cpan.org/Public/Bug/Display.html?id=119985 But if it does great.


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.