lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Wenjie Zhang (Jack)" <wenjiezhang2...@gmail.com>
Subject Re: Strange Alias behavior
Date Fri, 19 Jan 2018 22:22:01 GMT
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.homer@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.

Mime
View raw message