<    March 2017    >
Su Mo Tu We Th Fr Sa  
          1  2  3  4  
 5  6  7  8  9 10 11  
12 13 14 15 16 17 18  
19 20 21 22 23 24 25  
_2_6 27 28 29 30 31
00:17 aidalgol joined
00:18 Quintasan joined
00:18 Quintasan joined
00:18 GitHub114 joined
00:18 <GitHub114> [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
00:18 GitHub114 left
00:23 GitHub141 joined
00:23 <GitHub141> [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
00:23 GitHub141 left
00:27 GitHub166 joined
00:27 <GitHub166> [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
00:27 GitHub166 left
01:29 A124 joined
01:54 A124 joined
02:07 jaequery joined
03:47 nirvdrum joined
03:51 haennar joined
03:53 nirvdrum joined
07:02 glennpratt joined
07:47 glennpratt joined
07:50 glennpratt joined
07:56 glennpratt joined
08:10 Bish joined
08:10 ta_ joined
08:23 glennpratt joined
08:51 ta_ joined
09:01 ta_ joined
09:38 haennar joined
10:35 Bish joined
11:33 haennar joined
11:41 haennar joined
12:43 haennar joined
13:10 Bish joined
13:14 haennar joined
14:47 brybeecher joined
14:48 <Bish> im getting can't save frozen object, but before i save, i checked it, it's not frozen :p
14:48 <Bish> :o
15:01 glennpratt joined
15:19 glennpratt joined
15:23 mewp joined
16:34 dreinull joined
16:41 glennpratt joined
16:43 glennpratt joined
17:06 glennpratt joined
18:32 ta_ joined
19:28 scratchcat joined
19:30 <scratchcat> 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
19:35 <jeremyevans> 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
19:36 <jeremyevans> 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)
19:37 <scratchcat> 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.
19:38 anazar_ joined
19:38 <scratchcat> I could call each enum a different name (but they have the same values). Not sure what the *best* protocol is
19:38 <jeremyevans> 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)
19:40 <scratchcat> 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"
19:41 <scratchcat> the update_status reference cannot be found.
19:41 <scratchcat> (And it is actually run together)
19:42 <jeremyevans> 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
19:43 <scratchcat> Sure, should I send it here, or where?
19:47 <scratchcat> 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?
20:15 ta_ joined
20:18 haennar joined
20:41 ta_ joined
21:25 <jeremyevans> scratchcat: Yep, migrations should assume that previous migrations have already been run
22:23 irclogger_com joined
22:23 Topic for
22:56 ta_ joined
23:34 <scratchcat> 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?
23:45 <scratchcat> (also applies to another situation in which in general i just want to set the primary_key to be something I determine)