Why would you create an alias with an existing collection name? Sent from my iPhone
> On Jan 19, 2018, at 14:14, Webster Homer <webster.ho...@sial.com> wrote: > > 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.
