On Wednesday, September 7, 2016 at 1:29:43 PM UTC-5, Jeremy Evans wrote:
>
> In general, I recommend using CURRENT_TIMESTAMP in queries instead of
> literal timestamp values representing the current timestamp (which is what
> you get if you use Time.now.utc). I'm guessing you are using the
>
Hello,
I ran into a problem where I'm trying to compare two timestamps, one of
which is an updated_at timestamp that is automatically set when a record is
marked as processed, to use my app's domain language. So, this query
returns too many records:
Person.where('updated_at > processed_at')
On Friday, September 2, 2016 at 2:31:29 PM UTC-5, Jeremy Evans wrote:
>
> I'm guessing streaming would preform better, but you would still need to
> use a separate thread or sharding when using streaming.
>
That's great. I'll give streaming a try, but I believe the bottleneck isn't
going to be
On Friday, September 2, 2016 at 1:19:02 PM UTC-5, Jeremy Evans wrote:
>
> To work around this issue, you can use sharding (Dataset option like
> :servers=>{:foo=>{}}), and do dataset.server(:foo).paged_each.
> Alternatively, you can issue queries in a separate thread inside the
> Dataset#each
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
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
