Deprecate serialized_attributes without replacement

[sgrif]

We've stopped using it internally, in favor of polymorphism. So should
you!

[matthewd]

Isn't this internal API?

[sgrif]

@matthewd Updated.

[senny]

@sgrif 👍

[xaviershay]

I'm getting this deprecation just by using the serialize DSL method, then calling update_attributes. Is that expected? I don't see anything here about the serialize API as such. On 4.2.0.

[sgrif]

You should not see that deprecation warning from Rails. It's probably a gem causing that issue for you. If you can reproduce the issue using just Rails, please open an issue with a script we can use to reproduce the issue using https://github.com/rails/rails/blob/master/guides/bug_report_templates/active_record_master.rb as a template.

[xaviershay]

Ah, found it. For anyone who stumbles across this, pretty sure it was this gem/issue causing it: paper-trail-gem/paper_trail#416

[simi]

What about when you need this meta data before table is created (in migration)? You can check our example globalize/globalize#407.

[baweaver]

Whenever things like this are removed, it would be prudent to add additional details in the deprecation warnings as to how to properly approach the issue. It strikes me as a bit irresponsible to deprecate with no clear migration paths for those that aren't keen on polymorphism.

Whether or not it's better or more correct is irrelevant, a deprecation needs to be explained in more detail so as to provide the rationale behind it. To the core team that may be perfectly clear, but for an outsider to see something like we're using X now because X is better can be confounding.

For anyone who manages to stumble on this wondering what polymorphics are, this may be of assistance:
http://www.gotealeaf.com/blog/understanding-polymorphic-associations-in-rails

Is there a standard approach to deprecation that can be updated to include the rationale behind changes and a bit more meta? It'd provide a lot of value in upgrades and migrations to new versions.

[sgrif]

Polymorphism actually refers to asking an object to do something without caring about how it accomplishes it. This doesn't have anything to do with associations. It's a general programming term. http://en.wikipedia.org/wiki/Polymorphism_%28computer_science%29 This deprecation came from a lot of refactoring work where the rest of Active Record didn't need to care about the internals of what columns were serialized. We instead have attribute assignment work consistently, and delegate any behavior that needs to change for serialized attributes to the serialized type object, which sits where the other types would have lived. Continuing to maintain this method would have caused more problems than it solved. If you need help figuring out the right way to migrate forward, opening a thread on the mailing list might be a good place to start. Coming here and telling me why "I'm doing it wrong" isn't a great way to open a dialog.

[baweaver]

But should it be the duty of the mailing list / IRC / etc to fill in the blanks? What I'm saying is more information would be helpful, and I'm sorry if you took that as a personal affront, I didn't mean it as such. It just becomes tedious to hunt some of these things down as occasionally a seemingly minor feature can balloon out quickly whether it be from dependencies or your own code.

[sgrif]

But should it be the duty of the mailing list / IRC / etc to fill in the blanks?

If by the fill in the blanks, you mean be a communication channel for us when people have concerns they need to express? Yes. That's exactly what they're for...

What I'm saying is more information would be helpful

What information are you looking for? All you've said is "how could you not give more details this is so wrong". The rationale was that this method didn't feel needed any longer, it was a burden to keep it around. I'm not sure what "additional information" you're looking for. If you have code that depends on it, a better way to start would have been "Hey, I'm doing X and I'm not sure how to move forward", and then this conversation would be about what you could be doing in your code instead, rather than arguing about deprecation warnings.

[chancancode]

@baweaver perhaps to put it another way, there are two kind of deprecations: with and without replacement.

The former refers to cases there is still a legitimate need for the thing being deprecated, in which case we will try to recommend migration options in the message itself or in the upgrade guides.

The latter is for things that we recognized as "it was a bad idea afterall", or otherwise no longer necessary because of other improvements, or things that we can no longer support. (e.g. new Ruby versions has a similar thing, or we switched the implementation so supporting that is not feasible).

This particular implementation falls under the latter bucket. We'll try (within reasons) to associate these information to the commits, but like Sean said, for this case it seems appropriate to use the mailing list for this.

[KelseyDH]

Could somebody outline how existing applications using serialized_attributes can migrate to Rails 5? I'm sure sound reasons exist to deprecate this feature, but breaking API changes without (what appears to be) a viable path for migration worries me heavily.

Many Rails apps rely on popular gems that use serialized_attributes, such as paper_trail, rails_admin & identity_cache. Making sure these popular gems can gracefully migrate away from serialized_attributes is imperative IMO, or else I see existing projects facing a wall of frustration when they try to upgrade.

[senny]

@KelseyDH I feel like we have discussed this matter over and over again. The mentioned gems have already taken action to prevent the warnings and be ready for Rails 5.

• rails_admin: Rails 4.2 has deprecated serialized_attributes railsadminteam/rails_admin#2140
• paper_trail: Rails 5 is removing serialized_attributes without replacement paper-trail-gem/paper_trail#416

Help was provided in these discussions and a viable solution was found.

While Rails does not offer a direct successor to serialized_attribtues, there are ways to achieve the same behavior when necessary. The new type-casting facility also makes some uses of this method obsolete.

Let us know when there are concrete issues with upgrading on a gem or application and we'll be happy to discuss it.

[KelseyDH]

@senny thank you for responding. I chimed in because a viable upgrade path did not appear to exist within these discussions. I'm happy to see good progress is under way.

You might be receiving more attention than expected for this deprecation because of people mistakenly associating a deprecation of serialized_attributes with a deprecation of serialize. (I admit I made that mistake until I looked closer at the PR you provided.)

[jlaw90]

I am currently working on a project that includes per-attribute searching. As a sensible default for which columns to search, it grabs all columns with content_columns and then removes all serialized attributes using serialized_attributes - seeing as searching serialized attributes is probably not what's intended.

I don't see how this particular use case could be safely upgraded by using polymorphism?

[mathieujobin]

Why isn't there anything on the upgrade guide about this?

http://guides.rubyonrails.org/upgrading_ruby_on_rails.html