I just discovered some odd behavior with aliases. We are in the process of converting over to use aliases in solrcloud. We have a number of collections that applications have referenced the collections from when we used standalone solr. So we created alias names to match the name that the java applications already used.
We still have collections that have the name of the alias. We also decided to create new aliases for use in our ETL process. I have 3 collections that have the same configset which is named b2b-catalog-material collection 1: b2b-catalog-material collection 2: b2b-catalog-material-180117 collection 3: b2b-catalog-material-180117T When the alias, b2b-catalog-material-etl is pointed at b2b-catalog-material and the alias b2b-catalog-material is pointed to b2b-catalog-material-180117 and we do a data load to b2b-catalog-material-etl We see data being added to both b2b-catalog-material and b2b-catalog-material-180117 when I delete the alias b2b-catalog-material then the data stopped loading into the collection b2b-catalog-material-180117 So it seems that alias resolution is somewhat recursive. I'm surprised that both collections were being updated. Is this the intended behavior for aliases? I don't remember seeing this documented. This was on a solrcloud running solr 7.2 I haven't checked this in Solr 7.2 but when I created a new collection and then pointed the alias to it and did a search no data was returned because there was none to return. So this indicates to me that aliases behave differently if we're writing to them or reading from them. -- This message and any attachment are confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, you must not copy this message or attachment or disclose the contents to any other person. If you have received this transmission in error, please notify the sender immediately and delete the message and any attachment from your system. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not accept liability for any omissions or errors in this message which may arise as a result of E-Mail-transmission or for damages resulting from any unauthorized changes of the content of this message and any attachment thereto. Merck KGaA, Darmstadt, Germany and any of its subsidiaries do not guarantee that this message is free of viruses and does not accept liability for any damages caused by any virus transmitted therewith. Click http://www.emdgroup.com/disclaimer to access the German, French, Spanish and Portuguese versions of this disclaimer.
