[13sequel] 15Aryk commented on issue #549: Yeah, the whole to_json thing is quite a nasty issue due to ActiveSupport's treatment of things. They are some redeeming qualities however. I like the as_json convention as a precursor to the to_json.... 02https://git.io/vyswl
[13sequel] 15jeremyevans commented on issue #549: I'm leery of using any additional parts of ActiveSupport in the plugins/extensions that ship with Sequel (we currently use ActiveModel::Naming in the active_model plugin and ActiveSupport::Duration in the pg_interval plugin). But that sounds like a good idea for an external plugin. 02https://github.com/jeremyevans/sequel/issues/549#issuecomment-283516063
[13sequel] 15Aryk commented on issue #549: Makes sense! Will look into making an extension if it becomes a burning problem. For now I'm just using the JSON.dump which seems to be ok... 02https://git.io/vysrR
im getting can't save frozen object, but before i save, i checked it, it's not frozen :p
Hey, I'm having an issue with migrations, any help would be appreciated. I'm using a Date<threenumbers>_<description>.rb format for my migration files. My first migration file creates an enum that is accessed through the following migration files. In general, this works fine. However, one my date increments by one for a migration file, it seems it cannot find the enum anymore. Do I need to redefine the enum for every new dat
scratchcat: In general, what you define in one migration file will not be visible in another migration file, unless both migration files are loaded together
scratchcat: You definitely shouldn't rely in the migrations being loaded together, you should make sure each migration is independent (in terms of the ruby code, not in terms of database state)
How would you access the same column type (defined by enum) then? I tried to redefine the enum into each file, but it throws an erorr for enum already saved.
I could call each enum a different name (but they have the same values). Not sure what the *best* protocol is
scratchcat: You'd have to provide some examples. If you aren't trying to modify the enum, then just referencing the enum type in migrations after creating the enum should suffice (on PostgreSQL, enums behavior is database dependent)
Yeah, I don't modify the enums at all. For example, in 20170223020_create_x_table.rb does "create_enum :update_status, %w(…)". Then in 20170224020_create_y_table.rb does "create_table( :y_table) do update_status :status …end"
the update_status reference cannot be found.
(And it is actually run together)
scratchcat: that looks like it should work. Can you prepare a small self contained example including an SQL log? I should be able to review later today
Sure, should I send it here, or where?
Actually, I resolved it, it was a bug on my end. Quick question though, in this circumstance, just referencing the enum created previously (with the assumption that it has been created becuase it's created in a lower index migration) is the proper usage?
scratchcat: Yep, migrations should assume that previous migrations have already been run
Great, thanks. Also, I want to set the primary_key of a row to be the id of another row in another table (e.g. i label the column as foreign_key :name_id, …., primary_key: true, however I'm limited with the error "name_id is a restricted primary key"). I know I can use unrestrict_primary_key to allow setting via Model.create, however that's not ideal. Is there a better way to do this?
(also applies to another situation in which in general i just want to set the primary_key to be something I determine)