Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing documentation on how to handle replicas #348

Open
MaSpeng opened this issue Jun 18, 2020 · 5 comments · Fixed by #365
Open

Missing documentation on how to handle replicas #348

MaSpeng opened this issue Jun 18, 2020 · 5 comments · Fixed by #365

Comments

@MaSpeng
Copy link

MaSpeng commented Jun 18, 2020

  • Symfony version: 4.4.5
  • Algolia Search Bundle version: 4.1.0
  • Algolia Client Version: 2.5.1
  • Language Version: 7.4.1

Description

The current documentation about the integration of the search bundle is missing how to handle replicas the right way.
I was able to sort some steps out and bypass the issue which is mentioned in: #269.

My target is to provide an index with multiple replicas and distinct sort configurations, aside from that it must me possible to export all index settings and apply them during an application deployment.

1. Backup and restore index configurations using the cli search:settings:backup:

  • if an index is listet in the algolia_search.yaml it's configuration will be exported as expected, including the information about it's replicas
  • the configuration from the replicas itself are not exported this way

To also export the configurations of the replicas, it is required to list them all one by one in the algolia_search.yaml as seen down in the section "Steps To Reproduce".

2. Import data into an index using the cli search:import:

  • if the index and it's replicas are configured in the algolia_search.yaml, an import will lead to an exception during the unwanted push to a replica instead to the master:
In ApiWrapper.php line 210:

  cannot apply a add object request on a replica index

To bybass this issue it is required to provide the --indices option with the name of the master index. It is also required that the master index has to be the last which is configured in the algolia_search.yaml. This is the mentioned bypass for the issue: #269.

Steps To Reproduce

Example algolia_search.yaml to show how it is currently possible to use replicas with the search bundle.

algolia_search:
  prefix: ""
  doctrineSubscribedEvents: []
  indices:
    - name: index_property_asc
      class: Vendor\Orm\Entity\IndexEntity

    - name: index_property_desc
      class: Vendor\Orm\Entity\IndexEntity

    - name: index
      class: Vendor\Orm\Entity\IndexEntity

Summary

I would really like to see additional informations about this in the official documentation on how to do it the right way.

Also i would really appreciate further improvements in the search bundle to either be able to avoid the requirement to configure each replica or to be able to provide a specific configuration for them and also a proper handling for replicas in the cli to avoid unwanted exceptions during import.

@keichinger
Copy link

We're running into the same issue here with a couple of projects that rely on replicas.

Thanks for the workaround @MaSpeng. It's not really ideal, but at least something we can work with in the meanwhile.

I really hope that the search bundle can be improved to better handle replicas so that we can export the entire index graph with all of its replicas and its corresponding configurations, so that setting up an entire environment is as easy as running a single command.

Right now we're following the workaround and have to remove the replicas key from the export manually to make it work. It works, but manual, error-prone labour with each update to the search settings is nothing we'd want to keep permanently.

@maciekpaprocki
Copy link
Contributor

This really should get some attention.

The fix provided does not work when working with prefix. ex:

algolia_search.yaml

algolia_search:
    prefix: '%env%'
    indices:
        -   name: products_price_asc
            class: App\Entity\Product\Product
            index_if: isSearchable
        -   name: products
            class: App\Entity\Product\Product
            index_if: isSearchable

running php bin/console search:settings:backup --indices=products,products_price_asc. Will produce two files, both of which have config with filled in prefix ( given dev env ):

products-settings.json

{"replicas": ["dev_products_price_asc"]}

products-price-asc-settings.json

{"primary": ["dev_products"]}

Unfortunately, when you try to push that when in prod environment, those prefixed replicas/primary fields will throw an error.

@maciekpaprocki
Copy link
Contributor

Another note, after a bit of investigation:

Issue would be possible to fix by replacing DI of \Algolia\SearchBundle\Settings\SettingsManager and injecting our own service. Unfortunately, this class is final and DI is not based on interface, so we are pretty much blocked when trying to fix it.

Temporary solution would be to remove final at least, but ideally implement interface and base DI on that. This would allow us to extend the command with replica functionality.

maciekpaprocki added a commit to maciekpaprocki/search-bundle that referenced this issue Sep 18, 2021
Would allow us to implement our own SettingsManager that supports replicas. 

algolia#348
DevinCodes pushed a commit that referenced this issue Oct 7, 2021
Would allow us to implement our own SettingsManager that supports replicas. 

#348
@maciekpaprocki
Copy link
Contributor

maciekpaprocki commented Oct 13, 2021

My addition wasn't in anyway fixing the issue, it was just enabling us to patch it until the solution is ready.

The ticket should be open as it is still missing functionality, even that is super needed.

@DevinCodes DevinCodes reopened this Oct 14, 2021
@DevinCodes
Copy link
Contributor

You're right, it got closed automatically because of the fix #365 syntax. Thanks for the ping on this 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants