Looking at the other delta options, it seems that using the datetime delta will solve my issue, since it goes off of the updated_at timestamp.
I'm wondering why the delayed delta is preferred over this? It seems like delayed delta is more efficient in terms of turnaround time (i.e. how quickly the changes gets indexed), but since it causes 2 inserts for each update (as well as the updates on those records once the delayed job is handled), it seems that its pretty inefficient in terms of the load it places on the database. Especially for high volume transactions. Pat, any gotcha's or reasons I should stay away from the datetime delta? Thanks. On Apr 4, 6:15 pm, gmoniey <[email protected]> wrote: > I have a scenario where some fields in certain tables are updated from > an external service directly in the db. Currently the models are using > delayed_job to index the changes (set_property :delta => :delayed), > and I'm trying to figure out how to implement this externally. > > I looked into this a bit, and found that 2 jobs are being inserted > into the db for each update (DeltaJob & FlagAsDeletedJob). It seems > that I can replicate everything that needs to be inserted except for > the 'document_id'. > > I looked at the ts source a bit, and it seems document id is the > sphinx id for that particular model, which is something I wont have > access to. > > These updates happen often enough where I can't kick of a new ts:index > call, since that is too intensive. > > Do I have any other options here? -- You received this message because you are subscribed to the Google Groups "Thinking Sphinx" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/thinking-sphinx?hl=en.
