jackkrupansky Software, Support, and Training for Apache Cassandra en-US Mon, 20 May 2013 22:13:59 +0000 http://bbpress.org/?v=1.0.3 q http://www.datastax.com/support-forums/search.php http://www.datastax.com/support-forums/topic/dse-30-with-solr-support-for-integer-type#post-11193 Fri, 17 May 2013 22:01:34 +0000 Jack Krupansky 11193@http://www.datastax.com/support-forums/ <p>Patricia,</p> <p>Simply ignore that irrelevant phrase, ", Solr fields must be strings". The intent is simply that a Solr schema field can only be associated with a simple, non-composite Cassandra column. DSE does in fact support all the common types, as shown in that table, although you need 3.0.1 for the best type support; 3.0 mapped the Solr trie numeric types to UTF8Type, for example, as shown in the legacy type mapping table. </p> http://www.datastax.com/support-forums/topic/dse-30-with-solr-support-for-integer-type#post-11192 Fri, 17 May 2013 21:14:34 +0000 pgorla 11192@http://www.datastax.com/support-forums/ <p>Matt,</p> <p>I was also confused by this syntax. This sentence comes from this context:</p> <pre><code>Unsupported Features: &lt;...&gt; Cassandra composite columns, Solr fields must be strings.</code></pre> <p>The phrase "Solr fields must be strings" actually refers to the fact that each field must be of the same type. This means that composite columns are not supported, because composite columns actually contain two different data types. Solr requires that all values of a field share a type definition.</p> <p>So, DSE *does* support other types, such as int, date (see <a href="http://www.datastax.com/docs/datastax_enterprise3.0/solutions/dse_search_schema#solr-type-mapping)" rel="nofollow">http://www.datastax.com/docs/datastax_enterprise3.0/solutions/dse_search_schema#solr-type-mapping)</a> </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>