ice_cube icon indicating copy to clipboard operation
ice_cube copied to clipboard

Rails: Make Schedule.load Behave Like Other serialize()'d Objects

Open sshaw opened this issue 9 years ago • 3 comments

Values that are serialized via ActiveRecord's serialize return an instance of the serialized class if the attribute is nil. IceCube::Schedule#load returns nil.

sshaw avatar Jul 04 '16 16:07 sshaw

What should it return instead? It's hard to guess what the default value should be: I don't think it's safe to assume a single occurrence for Time.now.

I think nil is the right thing to load, unless we define a special "zero occurrence" schedule. Or am I missing something?

avit avatar Mar 21 '17 03:03 avit

It's hard to guess what the default value should be: I don't think it's safe to assume a single occurrence for Time.now.

serialize :some_column, IceCube::Schedule

Should return an instance of IceCube::Schedule.

I think nil is the right thing to load...

From the docs for serialize:

If class_name is specified, the serialized object must be of that class on assignment and retrieval.

When you return nil you break the contract.

unless we define a special "zero occurrence" schedule. Or am I missing something?

IceCube::Schedule.new seems fine. If I recall it is a "zero occurrence schedule".

sshaw avatar Mar 21 '17 03:03 sshaw

Every schedule stems from a start_time and occurs once for this time (by default it's Time.now, which would change on every new instance), before you add any recurrence rules. I get what you mean about the type contract but I don't think this would follow the expectation very well.

If the database is storing NULL (an absence of a specified value, not a default or new value) I don't see why we would want to assume anything from it: in this case the record object should not have any schedule until one is explicitly assigned.

Is this causing errors with ActiveRecord? We may have to return something different for handling the null object specially then.

As a side note, I see the docs also mention:

Empty objects as {}, in the case of Hash, or [], in the case of Array, will always be persisted as null.

So what this implies is that Rails expects nullable columns in the database, but requires their values to somehow still be specified in ActiveRecord!? This mixes up null and empty values as the same thing when they're really not... it's completely different from the type contract of any other kind of column. 😞

avit avatar Mar 21 '17 08:03 avit