Hmm..thats a little discouraging =[ I guess I could give it a try, since its so easy to switch between the two. My main concern with the delayed deltas is the 2 additional inserts for any crud operation.
I'll give it a shot, and let you know if I see anything weird. In my scenario, I will need to the cronjob to run every minute (or few minutes) since I want the updates to be pulled in as quickly as possible. This could also cause an issue on large tables (which hopefully an index on the updated_at field will help with) On Apr 6, 8:57 pm, Pat Allan <[email protected]> wrote: > The reason I recommend delayed deltas over datetime, is I've heard datetime > can sometimes be unreliable. I've not used it myself, so this is all based on > feedback. Still, if it fits what you're trying to do, give it a shot :) > > Also, regarding the document id - this is calculated from record primary > keys, with an offset. The offset shouldn't change generally - it's dependant > on the number and names of models being indexed (the offset is figured out > for models in alphabetical order). You can find that offset in the source in > your configuration file, so you could just use that little math expression > without issue. > > Cheers > > -- > Pat > > On 06/04/2011, at 5:56 PM, gmoniey wrote: > > > > > > > > > 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 > > athttp://groups.google.com/group/thinking-sphinx?hl=en. -- 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.
