Logging of prepared statement executions

I brought up the following in the comments of Jeremy's blog post on automatic statement caching, and he suggested that I bring it up here to get some input from other Sequel users. I'm thinking that when Sequel executes a prepared statement, it puts a line in the logs that looks something like "EX

Handling composite primary keys with the nested_attributes plugin.

I've been working on extending the nested_attributes plugin to handle child models with composite primary keys, and I've been able to get them to work just like models with single primary keys with minimal changes to the plugin ( https://github.com/chanks/sequel/commit/466391e901f47cba40127b0177

Re: Handling composite primary keys with the nested_attributes plugin.

Thanks, Jeremy. I'm going to just use :unmatched_key for now, and if anyone comes up with a better alternative it's a simple find-and-replace. Chris On Tuesday, May 29, 2012 2:23:55 PM UTC-7, Jeremy Evans wrote: > > On Tuesday, May 29, 2012 11:16:21 AM UTC-7, Chris Hanks wrote:

Syntax errors in sqlite

I'm working on expanding the association_pks plugin to work with composite primary keys. It's going well, but I don't know sqlite very well, and I'm stymied by some syntax errors I'm getting while trying to make the integration tests pass. In a nutshell, the problem is (taken from a debugging s

Comparing frozen/nonfrozen datasets

Just ran into this, which I wasn't expecting: > DB[:table].freeze == DB[:table] => false This is because the frozen state is stored in the opts hash, and Dataset#== compares the opts hashes. This might seem reasonable, but it clashes with Ruby's behavior more generally: > "string".freeze == "s

Two pieces of unexpected behavior

There are two things I ran across recently that aren't obviously bugs (so I decided to bring them up here rather than open issues), but do feel like unexpected behavior. #1 is minor: Refreshing/reloading an instance of a model when it doesn't exist in the DB anymore seems like it should probabl

Re: Two pieces of unexpected behavior

> > If you are only returning a single record, there is no reason to eager > load, it wouldn't save you any queries. > Yes, when I mentioned a more complex set of associations, I was referring to something like Post.eager(comments: {user: :followers}).first. I eager-load associations because I

Re: Two pieces of unexpected behavior

rsday, October 1, 2015 at 5:06:19 PM UTC-7, Chris Hanks wrote: >> >> If you are only returning a single record, there is no reason to eager >>> load, it wouldn't save you any queries. >>> >> >> Yes, when I mentioned a more complex set of associations, I

Re: Two pieces of unexpected behavior

Ah, cool! Thanks! On Fri, Oct 2, 2015 at 3:09 PM, Jeremy Evans wrote: > On Friday, October 2, 2015 at 8:29:48 AM UTC-7, Chris Hanks wrote: >> >> Yeah, none of the alternatives are really ideal, and I don't really have a >> need for eager_graph, so I think I'll

Mixing savepoints in testing with the retry_on option.

Hi all - I'm wrapping specs in transactions, and actually using Minitest::Hooks and the setup it suggests: def around_all DB.transaction(rollback: :always) { super } end def around DB.transaction(rollback: :always, savepoint: true, auto_savepoint: true) { super } end This has worked fine

Re: Mixing savepoints in testing with the retry_on option.

Sure, I'll try it tomorrow, thanks! On Thu, Nov 5, 2015 at 6:00 PM, Jeremy Evans wrote: > On Thursday, November 5, 2015 at 2:17:18 PM UTC-8, Chris Hanks wrote: >> >> Hi all - >> >> I'm wrapping specs in transactions, and actually using Minitest::Hooks an

Re: Mixing savepoints in testing with the retry_on option.

On Thursday, November 5, 2015 at 6:19:58 PM UTC-5, Chris Hanks wrote: > > Sure, I'll try it tomorrow, thanks! > > On Thu, Nov 5, 2015 at 6:00 PM, Jeremy Evans > wrote: > > On Thursday, November 5, 2015 at 2:17:18 PM UTC-8, Chris Hanks wrote: > >> > >

Respecting limits in custom eager blocks.

Hi - I'm using Sequel in an app that's servicing client requests written in GraphQL. The specifics aren't that important, the basic concept is that I'm dynamically generating eager-loading queries in response to client queries. For example, a query for users and their published posts will build

Re: Respecting limits in custom eager blocks.

would probably also be helpful to be able to specify an :eager_limit_strategy in the same call. Chris On Tuesday, December 8, 2015 at 10:57:09 AM UTC-5, Jeremy Evans wrote: > > On Monday, December 7, 2015 at 9:42:54 PM UTC-8, Chris Hanks wrote: >> >> Hi - >> >>

Extension for running after_commit hooks on savepoints.

Hi y'all - I've put together a Sequel extension to support after_commit and after_rollback hooks on savepoints. The most common use-case for this is in transactional testing, so that you can do: Pseudocode example: # Test setup def around # hooks: :savepoint makes after_commit and after_roll

Tweaking the null_dataset extension to not use Object#extend?

Hello - I'm using the null_dataset extension, which mentions a performance issue due to the use of Object#extend. It seems to me that we could get the same behavior simply by having nullify clone the ds with a "nullified" (or similar) dataset option, and the methods being overridden in that mod

Re: Tweaking the null_dataset extension to not use Object#extend?

Cool, totally agree this should be benchmarked. I'll throw it on my TODO list. :) On Monday, September 19, 2016 at 4:47:30 PM UTC-4, Jeremy Evans wrote: > > On Monday, September 19, 2016 at 12:24:07 PM UTC-7, Chris Hanks wrote: >> >> Hello - >> >> I'm

The column_select plugin raises an ambiguous error when the model's table doesn't exist.

I'm using column_select on all models in an application, and the server is booted but a table doesn't exist (usually because a dev forgot to migrate after switching branches), the following error pops up: /home/chris/.rvm/gems/ruby-2.3.0/bundler/gems/sequel-cc1e5c342b95/lib/sequel/plugins/column

Re: The column_select plugin raises an ambiguous error when the model's table doesn't exist.

Cool, makes sense. Thanks! On Thursday, October 27, 2016 at 12:46:51 PM UTC-4, Jeremy Evans wrote: > > On Thursday, October 27, 2016 at 8:59:13 AM UTC-7, Chris Hanks wrote: >> >> I'm using column_select on all models in an application, and the server >> is boo

Re: Possible Deprecation of Automatic Literal Strings

I'm a big fan of this change. Using raw SQL strings is an antipattern, frankly, and should be avoided whenever possible. If someone really wants to pass in a literal string to one of these methods, I don't think it's too much to ask for them to make that intention explicit with Sequel.lit(). Ch

Re: Using identity instead of serial by default for primary_key on PostgreSQL 10.2+

This will change the effects of old migrations, right? A migration that I wrote a year ago using `primary_key` that formerly created a `serial` column will now create an identity column. When I write a new migration to convert my serial primary keys to identity ones (because they do seem like a

Re: Using identity instead of serial by default for primary_key on PostgreSQL 10.2+

e fan of ActiveRecord in general, but they now have migrations declare what AR version they were written against, which helps when making changes to the migration API like this. On Friday, March 9, 2018 at 10:43:57 AM UTC-5, Jeremy Evans wrote: > > On Friday, March 9, 2018 at 6:45:26 AM UTC-8

Re: Sequel 5.13.0 Released

Hmm, seems like careless use of `constant_sql_override` could change the output/effect of old migrations? For example, if a migration sets a column default of CURRENT_TIMESTAMP, and then later the constant sql is set to "CURRENT_TIMESTAMP AT TIME ZONE 'UTC'", then development/production databas