rockbrain Software, Support, and Training for Apache Cassandra en-US Sat, 25 May 2013 13:01:57 +0000 http://bbpress.org/?v=1.0.3 q http://www.datastax.com/support-forums/search.php http://www.datastax.com/support-forums/topic/slow-delete-by-query-on-indexed-fields#post-11325 Thu, 23 May 2013 15:05:56 +0000 rockbrain 11325@http://www.datastax.com/support-forums/ <p>Each record is deleted from C*, we could probably parallelize that however the time does not look off. </p> http://www.datastax.com/support-forums/topic/slow-delete-by-query-on-indexed-fields#post-11323 Thu, 23 May 2013 12:29:36 +0000 jpayne97 11323@http://www.datastax.com/support-forums/ <p>Not sure how long a delete by a query should be taking, but for deleting 50961 records it took 73 seconds to delete. Both the fields in the query are indexed in the schema. Is this normal?</p> <p><a href="http://u060dc2d82:8983/solr/item.location/update?stream.body=%3Cdelete%3E%3Cquery%3E(div:014)AND(store:00305)%3C/query%3E%3C/delete%3E" rel="nofollow">http://u060dc2d82:8983/solr/item.location/update?stream.body=%3Cdelete%3E%3Cquery%3E(div:014)AND(store:00305)%3C/query%3E%3C/delete%3E</a></p> <p>&lt;response&gt;<br /> &lt;lst name="responseHeader"&gt;<br /> &lt;int name="status"&gt;0&lt;/int&gt;<br /> &lt;int name="QTime"&gt;73342&lt;/int&gt;<br /> &lt;/lst&gt;<br /> &lt;/response&gt; </p> http://www.datastax.com/support-forums/topic/cassandra-timestamp-to-solr-triedatefield#post-11159 Thu, 16 May 2013 22:28:54 +0000 datastaxnewbie 11159@http://www.datastax.com/support-forums/ <p>Thanks your help, I am creating Solr index before the CF (DSE 3.0.1). I also found out my time values are microseconds so I have changed the date fields to longs and converting them at the client side, unless it's possible to tell Solr that the time passed in is microseconds since epoch? </p> http://www.datastax.com/support-forums/topic/cassandra-timestamp-to-solr-triedatefield#post-11147 Thu, 16 May 2013 14:18:55 +0000 rockbrain 11147@http://www.datastax.com/support-forums/ <p>"I have a StartTime column in Cassandra that is typed as timestamp, and I created a corresponding field in Solr schema that is of TrieDateField. "</p> <p>The C* CF for Solr must be created by DSE when the schema is uploaded, otherwise the resulting behavior will be in-determinant, as you have seen. </p> http://www.datastax.com/support-forums/topic/cassandra-timestamp-to-solr-triedatefield#post-11099 Thu, 16 May 2013 02:40:51 +0000 Jack Krupansky 11099@http://www.datastax.com/support-forums/ <p>Maybe.... although the year "20114840" is quite a ways in the future! </p> http://www.datastax.com/support-forums/topic/cassandra-timestamp-to-solr-triedatefield#post-11098 Thu, 16 May 2013 01:41:03 +0000 rockbrain 11098@http://www.datastax.com/support-forums/ <p>'20114840-09-19T02:26:40Z' is the standard date format returned by Solr. There isn't anything wrong. </p> http://www.datastax.com/support-forums/topic/cassandra-timestamp-to-solr-triedatefield#post-11096 Thu, 16 May 2013 00:15:25 +0000 Jack Krupansky 11096@http://www.datastax.com/support-forums/ <p>What release of DSE are you using? It was DSE 3.0.1 which introduced enhanced datatype mapping which makes C* DateType/timestamp compatible with Solr DateField and TrieDateField. But in DSE 3.0 and 2.x, you must use UTF8Type for a Solr TrieDateField. </p> http://www.datastax.com/support-forums/topic/cassandra-timestamp-to-solr-triedatefield#post-11094 Wed, 15 May 2013 23:44:02 +0000 datastaxnewbie 11094@http://www.datastax.com/support-forums/ <p>Hi,</p> <p>I have a StartTime column in Cassandra that is typed as timestamp, and I created a corresponding field in Solr schema that is of TrieDateField. When I stored the following timestamp into Cassandra, I get back the same value (4/15/2012 12:26:22 PM). When I retrieve the document through Solr using the same row key (id), the value that I get back for that same field is "20114840-09-19T02:26:40Z", which doesn't appear to be an ISO8601 format either. Do I need to set the precisionStep in Solr schema for that field? What am I doing wrong?</p> <p>Thanks,</p> <p>Paul </p> http://www.datastax.com/support-forums/topic/dse-30-reindexing-is-not-working-for-solr-copyfield#post-11030 Wed, 15 May 2013 00:59:46 +0000 jwlee 11030@http://www.datastax.com/support-forums/ <p>Sergio,</p> <p>All right. Good to hear it is in the plan.<br /> We'll do the workaround in the meantime.</p> <p>Thanks!<br /> Regards,<br /> JW </p> http://www.datastax.com/support-forums/topic/dse-30-reindexing-is-not-working-for-solr-copyfield#post-11007 Tue, 14 May 2013 07:24:59 +0000 sergio 11007@http://www.datastax.com/support-forums/ <p>Hi,</p> <p>the reason we don't currently support reindexing of *new* copy fields is that we always store them in Cassandra (that is, we always assume stored=true), hence we need the copy field value to be known upfront at ingestion time.</p> <p>We are planning to support non-stored mode too (that is, stored=false): this will not store any copy fields in Cassandra, but will allow for them to be reindexed post-ingestion, even new ones.</p> <p>In the meantime, you can use the workaround provided above.</p> <p>Hope that helps.<br /> Cheers,</p> <p>Sergio B. </p> http://www.datastax.com/support-forums/topic/dse-30-reindexing-is-not-working-for-solr-copyfield#post-10999 Tue, 14 May 2013 03:35:59 +0000 jwlee 10999@http://www.datastax.com/support-forums/ <p>Thanks to all for your replies.<br /> Just want to add that the copyfield is an important feature for us.<br /> We are frequently changing the Solr schema to suit the search behaviors required by our users.<br /> Really do hope that the reindexing for the copyfields are automatically applied.<br /> After all, isn't it suppose to be ETL free? </p> http://www.datastax.com/support-forums/topic/dse-30-reindexing-is-not-working-for-solr-copyfield#post-10976 Mon, 13 May 2013 16:28:44 +0000 rockbrain 10976@http://www.datastax.com/support-forums/ <p>Tristan,</p> <p>The following contains the examples necessary to use the CopyFieldInputTransformer.</p> <p><a href="http://pastebin.com/bi7cLQud" rel="nofollow">http://pastebin.com/bi7cLQud</a></p> <p><a href="http://pastebin.com/MpbnCNsH" rel="nofollow">http://pastebin.com/MpbnCNsH</a> </p> http://www.datastax.com/support-forums/topic/dse-30-reindexing-is-not-working-for-solr-copyfield#post-10975 Mon, 13 May 2013 15:39:10 +0000 tristanls 10975@http://www.datastax.com/support-forums/ <p>Jack, that's good to hear. My main concern was that this might get dropped, but that's been alleviated.</p> <p>Also, I only get to complain on these forums, but overall it's been a pretty easy and good experience so far. So keep up the good work. </p> http://www.datastax.com/support-forums/topic/dse-30-reindexing-is-not-working-for-solr-copyfield#post-10974 Mon, 13 May 2013 15:19:33 +0000 Jack Krupansky 10974@http://www.datastax.com/support-forums/ <p>Tristan, thanks for the detailed justification - it will help fuel our internal discussions.</p> <p>Why not do it? Timeframe, priorities, compatibility, perceived importance, architectural complexity - the usual bane of software engineering. It sometimes just takes some time to work through it all. But, rest assured, it is on our radar. copyField is a very important Solr feature.</p> <p>Workarounds are, by definition, never good architecture. They're simply temporary, stopgap measures. </p> http://www.datastax.com/support-forums/topic/dse-30-reindexing-is-not-working-for-solr-copyfield#post-10970 Mon, 13 May 2013 15:09:53 +0000 tristanls 10970@http://www.datastax.com/support-forums/ <p>rockbrain, yes, it would be great to know even if it's brittle right now and might change </p>