<    June 2018     >
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 _2_3  
24 25 26 27 28 29 30
07:11 claudiuinberlin joined
08:06 Morrolan joined
09:22 GitHub93 joined
09:22 <GitHub93> [13sequel] 15celsworth opened issue #1525: tree plugin functions break with renamed children association 02https://git.io/vjQa9
09:22 GitHub93 left
09:30 ta_ joined
09:33 ta_ joined
10:13 ta_ joined
12:18 pdrakeweb joined
15:05 GitHub125 joined
15:05 <GitHub125> [13sequel] 15jeremyevans commented on issue #1525: Thanks for the report. This is definitely a bug. I have a fix locally, just working on tests for it now. Should be pushed up to GitHub later today. 02https://git.io/fvLd4
15:05 GitHub125 left
15:30 GitHub43 joined
15:30 <GitHub43> [13sequel] 15jeremyevans closed issue #1525: tree plugin functions break with renamed children association 02https://git.io/vjQa9
15:30 GitHub43 left
15:30 GitHub130 joined
15:30 <GitHub130> [13sequel] 15jeremyevans pushed 4 new commits to 06master: 02https://git.io/fviJy
15:30 <GitHub130> 13sequel/06master 143dd8554 15Jeremy Evans: Use while instead of each in postgres adapter inner loop...
15:30 <GitHub130> 13sequel/06master 144c26a27 15Jeremy Evans: Treat read-only mode error as disconnect error on mysql and mysql2 adapters, for better behavior on AWS Aurora cluster...
15:30 <GitHub130> 13sequel/06master 14f0d0c38 15Jeremy Evans: Make sure MT_NO_PLUGINS is set before minitest is loaded in all spec suites
15:30 GitHub130 left
16:20 <Caesium> jeremyevans: I've developed a requirement to use the list plugin with a range of existing data that uses 0 as the top of the list. What are the chances that you might accept a PR to allow setting the top of the list to an Integer (defaulting to existing behaviour, 1) ?
16:22 <Caesium> I guess my alternatives are to write some super()s around the list plugin in my own local modified copy of it, or something
16:22 <jeremyevans> Caesium: Should be fine as long as it doesn't change the default behavior
16:23 <Caesium> great, I'll see what I can come up with :) thanks for fixing the tree bug too :)
16:23 <jeremyevans> Caesium: Other than move_to_top there might not be any other methods affected
16:23 <Caesium> there is a check for < 1 as well
16:23 <Caesium> but yes, I only found two places I had to change (in a bodge to see if it'd work at all)
17:12 GitHub1 joined
17:12 <GitHub1> [13sequel] 15celsworth opened pull request #1526: Add :top as an option in the list plugin (06master...06list-top-option) 02https://git.io/ffCOd
17:12 GitHub1 left
17:21 GitHub137 joined
17:21 <GitHub137> [13sequel] 15jeremyevans commented on issue #1526: Thanks for the patch! This looks like a good starting point, I'll probably just make a couple changes after merging. Should have this committed later today. 02https://git.io/ffCs8
17:21 GitHub137 left
17:23 eydaimon joined
17:24 <eydaimon> if I'm doing something like a DB['select * from table'].each { |row| ... } can I chunk it somehow, or is there any consideration I can easily do for a db in production to not overwhelm it ?
17:25 <Caesium> the closest thing I can think of is the pagination plugin, but its not really what its designed for :)
17:26 <Caesium> https://www.rubydoc.info/github/jeremyevans/sequel/Sequel%2FDataset:paged_each
17:26 <Caesium> oh actually thats not part of the plugin, its in Dataset. so that'd be ideal :)
17:27 <eydaimon> what do you mean ?
17:27 <Caesium> nothing, ignore. you want paged_each :)
17:27 <eydaimon> paged_each ? and it's already part of the ds ?
17:27 <Caesium> basically just replace .each with .paged_each :)
17:27 <Caesium> yeah
17:27 <Caesium> however note the warnings on that page that you need a defined sort order
17:28 <eydaimon> thanks man :)
17:28 <Caesium> otherwise you could get the same row more than once and bad things might happen
17:31 GitHub185 joined
17:31 <GitHub185> [13sequel] 15jeremyevans pushed 2 new commits to 06master: 02https://git.io/ffCGO
17:31 <GitHub185> 13sequel/06master 14971f0bd 15Chris Elsworth: Add :top as an option in the list plugin
17:31 <GitHub185> 13sequel/06master 14210cb8f 15Jeremy Evans: Minor tweak to list plugin :top option...
17:31 GitHub185 left
17:31 GitHub196 joined
17:31 <GitHub196> [13sequel] 15jeremyevans closed pull request #1526: Add :top as an option in the list plugin (06master...06list-top-option) 02https://git.io/ffCOd
17:31 GitHub196 left
17:45 <eydaimon> undefined method `destroy' for #<Sequel::Oracle::Dataset
17:45 <eydaimon> there's no destroy for oracle datasets ?
17:46 <jeremyevans> eydaimon: destroy is only for model datasets
17:46 <jeremyevans> eydaimon: regular datasets should use delete
17:46 <eydaimon> ok
17:46 <jeremyevans> eydaimon: in general, unless you have destory hooks in the model, you should always use delete
17:46 <eydaimon> thanks
17:52 ta_ joined
18:48 plujon joined
18:52 <plujon> sequel -d postgres:///mydb | grep -A3 schema_info # why is schema info in the migration?
18:52 <plujon>
18:53 <plujon> sequel -d postgres:///mydb >test/migrate/001_init.rb && rake test # fails with Sequel::DatabaseError: SQLite3::SQLException: table `schema_info` already exists
18:53 <plujon>
18:57 <jeremyevans> plujon: You need to remove the schema_info table, it's part of the dump, but the migrator automatically creates it
18:58 <plujon> Right; I see that if I remove that table it works.
18:59 <plujon> jeremyevans: Thanks. Is there a good reason to dump schema_info in the first place? Is `sequel -d` not normally intended to create a file that can be used as a migration?
19:01 <jeremyevans> plujon: the assumption is if you already have migrations, you would just run those instead of dumping. The idea with sequel -d is to dump a migration file for a database that has not previously used migrations.
19:02 <plujon> FWIW, the reason I'm doing this: migrate/0*.rb contains postgres-specific code. But I want tests to use Sequel.sqlite.
19:03 <plujon> The postgres-specific code is not really important for the tests.
19:04 <jeremyevans> plujon: Risky business, but if you want to do that, instead of using the migrator, just run the migration file on the database directly using the Migration API
19:04 <plujon> So, I was looking for a way to copy the schema. I thought the redirection above (`sequel -d ... >test/migrate/001_init.rb`) would be a cheap way to inform the test code of the proper schema.
19:05 <plujon> Ah, that sounds fine. I'll look at that...
19:05 <plujon> I want to run tests in Schema.sqlite for speed and temporary-i-ness.
19:06 <jeremyevans> plujon: load('test/migrate/001_init.rb'); Sequel::Migration.descendants.last.apply(DB, :up)
19:08 <plujon> jeremyevans: Cool, that's the magic! Thanks!
19:17 <plujon> FTR, the postgres-specific parts of my migrations are 'constraint :valid_email, :email => /^[^,;@ \r\n]+@[^,@; \r\n]+\.[^,@; \r\n]+$/'. I could (and probably should), code these as per the rodauth README (if db.database_type == :postgres ...)
19:20 <plujon> Even if I did that, though, I would probably still dump the current schema and load it to avoid superfluous ALTER TABLE statements when running tests. Although if the test database is empty to start, maybe those ALTER TABLE statements bear almost no cost...
20:50 <eydaimon> how do I mark a db field as being JSON serialized in a model ?
20:52 <jeremyevans> eydaimon: You can use the serialization plugin for models, or if you are using PostgreSQL, consider using the pg_json extension
21:04 <eydaimon> hm. I am indeed using postgres :)
21:09 <plujon> Apparently sqlite does not support renaming columns with foreign key constraints. I guess that is why I will prefer a dump-one-migration-and-load-schema strategy over running the actual migrations when testing.
21:13 <jeremyevans> plujon: SQLite is very limited in terms of data type support and schema changes in general. As its documentation states, it's better thought of as a replacement for fopen(3) than a replacement for a real database.
21:14 <jeremyevans> plujon: that's not to say SQLite is bad, but you basically have to design your application around its limitations if you plan to use it as a main database
21:16 Linell joined
21:19 <Linell> Probably a stupid question, but https://gist.github.com/Linell/3c37d3c08099c8b858ed550b0b2bd7d8
21:20 <Linell> Essentially I need to wrap an array of BooleanExpression objects in parenthesis
21:20 <Linell> Does anyone have any pointers on the right direction to look?
21:21 <jeremyevans> Linell: Can you explain why you want that. If all operators are AND, it shouldn't need parentheses around subexpressions
21:23 <jeremyevans> Linell: You could probably wrap the expressions where you want parantheses using Sequel::SQL::Wrapper, but I don't see why you would want the subexpressions wrapped
21:24 <Linell> in my head it's because the school years in the example are different, so while it could satisfy those conditions independently
21:24 <Linell> all students in 12th grade where they had <= 100 absences in 2017 and >= 7 in 2018
21:28 <Linell> Wrapper works like a charm, pending my logic just being wrong
21:31 <Linell> Thank you so much for your help!