0

I'm facing a complex problem which i haven't been able to resolve yet.

I'm using Rails 4(edge) with postgresql 9, ElasticSearch 0.20.6 and the gem Tire (0.5.7). I have multiple table that are linked together. for instance:

Agency has many Clients Clients has many Projects Projects has many Files

My goal here is to be able to index Files in two ways:

  • First have an index that just allows easy and rapid search among all files. That i have succeeded into doing just by using tire. My index has a type "file" and it works like a charm.
  • The other index I would like to create would have some of the files information but also some of the clients and the agencie's properties. This is for an external tool that would be able to fetch the best files according to criteria like the project's category or the client's location...

As i'm using postgresql, i was thinking i could do a database view and index data from there. I'm not sure it's good to do it like that though cause the view would be pretty complex with multiple joins. Plus i'm afraid that any update would trigger a full-database re-indexing.

I was wondering if there was a way to do a pure-tire model and easily trigger the index update on any of it's linked tables. For instance, i'll have indexed the data in a type named files_front. I would have a model FilesFront which has_one :file and each time i update a file or any parent, all the impacted files would see their values updated in ES.

I'm really not sure on how to do this, so any advice is welcome.

Crystark
  • 3,693
  • 5
  • 40
  • 61

1 Answers1

1

Having a separate, table-less or standalone model is a good solution. The problem here, I assume, is connecting the FileFront class to the rest of the system. Effectively, whenever you update the File or any associated Client etc. object, you need to update the FileFront object.

You could actually use the Model::Persistence to that. So for each File you'd have an associated FrontFile, which you would assemble as JSON in File and create/update in an after_save callback. The tricky part is ensuring changes to the parent objects are propagated to file, and vice-versa.

karmi
  • 14,059
  • 3
  • 33
  • 41