Sequel 4.38.0 Released

2016-09-01 Thread Jeremy Evans 
Sequel 4.38.0 has been released!

= New Features

* Sequel::SQL::NumericMethods#coerce has been added, which adds
  support for ruby's coercion protocol when performing numeric
  operations.  Previously, Sequel supported code like:

Sequel.expr{a - 1}

  This is because a in this case returns a Sequel::SQL::Indentifier,
  which defines #- to return a Sequel::SQL::NumericExpression.  By
  supporting #coerce, the following code now also works:

Sequel.expr{1 - a}

  This is because Integer#- calls #coerce on the argument if it is
  defined (ruby's coercion protocol).  Previously, you had to handle
  this differently, using something like:

Sequel.expr(1) - a
# or
Sequel.-(1, a)

* Sequel now supports the ** operator for exponentiation on
  expressions, similar to the +, -, *, and / operators.  Sequel uses
  the database power function to implement this by default on the
  databases that support it (most of them).  On Access, it uses the ^
  operator, on Derby it is emulated using a combination of exp/ln
  (with some loss of precision).  SQLite doesn't support a power
  function at all, but Sequel emulates it using multiplication for
  known integer exponents.

* Sequel::SQLTime.date= has been added, which allows you to set the
  date used for Sequel::SQLTime instances.  Sequel::SQLTime is a
  subclass of Time that is literalized using only the time components,
  and is the ruby class used to store values of database time columns
  on most adapters.  Sequel::SQLTime defaults to using the current
  date, but you can now set a specific date, for more consistency with
  some drivers (Mysql2 uses 2000-01-01, tiny_tds uses 1900-01-01).

* The postgres adapter now supports a :driver_options option when
  using the pg driver, which is passed directly to pg.  This can be
  used to specify a client SSL certificate or to specify the
  certificate authority root certificate when using
  :sslmode=>'verify-full'.

= Other Improvements

* Sequel no longer uses after_commit/rollback database hooks by
  default if the after_commit/after_rollback model methods are not
  overridden. This provides a performance speedup, but the main
  benefit is that it no longer causes memory issues when saving a
  large number of model instances in a single transaction, and it
  also works with prepared transactions/2 phase commit.  You can
  still set use_after_commit_rollback= manually to force the
  after_commit/rollback setting.

  Note that Sequel 5 will move after_commit/rollback model hooks to
  a plugin, and the default and recommended approach will be to use
  the database after_commit/rollback hooks in the after_save or
  similar model hooks.

= Backwards Compatibility

* The Sequel::Model use_after_commit_rollback class and instance
  methods now return nil by default instead of true.  nil now
  indicates the default behavior of checking whether the appropriate
  model hook has been defined, and only adding a database hook if so.

Thanks,
Jeremy

-- 
You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sequel-talk+unsubscr...@googlegroups.com.
To post to this group, send email to sequel-talk@googlegroups.com.
Visit this group at https://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.

Changing behaviour of regex filters for adapter

2016-09-01 Thread Eric Schwartz 
I'm working on updating a Sequel adapter (sequel-vertica) for my own 
nefarious purposes (actually, I'm adding support for COPY FROM STDIN), and 
I am running across a problem trying to get all the existing tests to pass.

It seems that when Sequel sees a dataset filter like: @ds.filter(name: /bc/) 
that it wants to turn this into WHERE "name" ~ /bc/ but Vertica doesn't 
support ~; instead it wants to use WHERE "name" REGEXP_LIKE('bc'). When I 
traced this, it seemed to be a result of looking up a set of filter types 
in Sequel::SQL::StringExpression::LIKE_MAP. I'm not clear on how I could 
coerce the Vertica adapter to use REGEXP_LIKE instead of ~ in this context. 
What should I try?

-=Eric

-- 
You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sequel-talk+unsubscr...@googlegroups.com.
To post to this group, send email to sequel-talk@googlegroups.com.
Visit this group at https://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.

Re: Transactions and paged_each

2016-09-01 Thread Trevor Turk 
On Thursday, September 1, 2016 at 1:20:21 AM UTC-5, Jeremy Evans wrote:
>
> Dataset#paged_each shouldn't lock the entire table, as it just selects 
> rows, but the behavior in regards to locking depends on the database.  It 
> would probably be best for you to try it in a test environment to be sure 
> it functions as you expect, before using it in production.
>
> Thanks,
> Jeremy
>

Thanks, Jeremy!

I'll do some thorough testing before running in production, and I'll report 
back about the eventual results for future readers. 

In my case, I'm on AWS RDS PostgreSQL version 9.3.10 and I'm using the 
"sequel" and "pg" gems. So, I'd be using cursors with paged_each as it 
stands. Do you know if that ought to be safe? I'm considering switching to 
the "sequel_pg" gem for the streaming support, but I'm reluctant to change 
things unnecessarily, unless streaming might work where cursors would not. 

Thanks again,
- Trevor

-- 
You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sequel-talk+unsubscr...@googlegroups.com.
To post to this group, send email to sequel-talk@googlegroups.com.
Visit this group at https://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.

Re: "delay_add_association" plugin and one_to_one relationship

2016-09-01 Thread David Espada 
2016-09-01 10:51 GMT+02:00 David Espada :

> I have tested and it doesn't wotk :(
>

Ouch! Now I understand that your example is not generic code, but a
redefinition of specific association code. Sorry :)

-- 
David

-- 
You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sequel-talk+unsubscr...@googlegroups.com.
To post to this group, send email to sequel-talk@googlegroups.com.
Visit this group at https://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.

Re: "delay_add_association" plugin and one_to_one relationship

2016-09-01 Thread David Espada 
2016-09-01 10:34 GMT+02:00 David Espada :

>
> 2016-08-31 18:40 GMT+02:00 Jeremy Evans :
>
>>   plugin :instance_hooks
>>
>>   def association=(v)
>>  after_save_hook{super}
>>   end
>>
>
> I'll try it. Thank you very much.
>

I have tested and it doesn't wotk :(

I have not found any reference to association= method in Sequel code. What
is the matter? I don't understand.

-- 
David

-- 
You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sequel-talk+unsubscr...@googlegroups.com.
To post to this group, send email to sequel-talk@googlegroups.com.
Visit this group at https://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.

Re: "delay_add_association" plugin and one_to_one relationship

2016-09-01 Thread David Espada 
2016-08-31 18:40 GMT+02:00 Jeremy Evans :

> That's certainly not the behavior of delay_add_association in the *_many
> association case, so it wouldn't make sense for it to be the default in the
> one_to_one case.  If you want that behavior, you can probably write your
> only plugin, or just do:
>
>   plugin :instance_hooks
>
>   def association=(v)
>  after_save_hook{super}
>   end
>

=8)

Is this code valid for all association types? If so, great!

I'll try it. Thank you very much.

-- 
David

-- 
You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sequel-talk+unsubscr...@googlegroups.com.
To post to this group, send email to sequel-talk@googlegroups.com.
Visit this group at https://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.

Re: Transactions and paged_each

2016-09-01 Thread Jeremy Evans 
On Wednesday, August 31, 2016 at 9:47:52 PM UTC-7, Trevor Turk wrote:
>
> Hello,
>
> I've been reading about paged_each and it seems to work well in my 
> testing, but I'm concerned about using it in production because the 
> documentation says it uses a transaction internally. 
>
> I plan to make a "backfill" script that iterates over all rows in a 
> production database and enqueues background jobs for processing them etc.
>
> Would using paged_each lock the table and prevent my (Sinatra) app from 
> functioning regularly?
>
> Thank you!
> - Trevor
>

Dataset#paged_each shouldn't lock the entire table, as it just selects 
rows, but the behavior in regards to locking depends on the database.  It 
would probably be best for you to try it in a test environment to be sure 
it functions as you expect, before using it in production.

Thanks,
Jeremy

-- 
You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sequel-talk+unsubscr...@googlegroups.com.
To post to this group, send email to sequel-talk@googlegroups.com.
Visit this group at https://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.