I have to say I like "the new way" of doing things. I'm sooo tired of maintaining a bunch of command-line files that copy everything from example to node1, node2, node3 then starting things up in 4 separate windows (or 6 recently) and... Hmmm, looks kind of similar to what the new command does all for me...
I'm a little discomfited by having to learn new stuff, but that's "a personal problem" ;). I do think we have to be mindful of people who want something like what Shawn was doing, I do this all the time as well. And of new people who haven't a clue. Hmmm, actually new folks might have an easier time of it since they don't have any expectations ;). bq: "...'run example' target that could also fire off a create for collection1." Exactly, with a note (perhaps in the help for this command) about where the config files are located that are used. Perhaps with a 'clean' option that blows away the current data directory and (if Zookeeper becomes the one source of truth) does an upconfig first. For me, the goal here is to be up and running as fast as I could be in the old way of doing things, i.e. 1> cd to XXXX 2> execute the command YYYY 3> go into exampledocs and type 'java -jar post.jar *.xml" 4> search The current questions (mine as well) are, as Mark says, that I'd expect with such a fundamental change. Now that it's checked in, people will be trying all sorts of things and uncovering nooks and crannies. So let's have an umbrella JIRA that we collect things in and we can fix what we find as we go. I'll create one if there isn't one already, let me know. Erick On Sun, Nov 2, 2014 at 4:06 PM, Alexandre Rafalovitch <arafa...@gmail.com> wrote: > That's interesting. I did not realize we were going away from > ElasticSearch on that. > > So, do we need to update the tutorial or some other super-obvious way > of what the next step is? (I haven't checked). Because one difference > between Solr and the Database is that create table is a standard SQL > command used in any database (for the basic use case). Whereas Solr is > a unique snowflake and we cannot expect any pre-existing knowledge > transfer. > > Regards, > Alex. > Personal: http://www.outerthoughts.com/ and @arafalov > Solr resources and newsletter: http://www.solr-start.com/ and @solrstart > Solr popularizers community: https://www.linkedin.com/groups?gid=6713853 > > > On 2 November 2014 18:06, Mark Miller <markrmil...@gmail.com> wrote: >> I'm sure after such a large change there are some things to smooth over. >> >> As far as starting with no cores or collections, I very strongly think that >> is the way to go. >> >> I've been working with a Solr checkout designed this way for a long time and >> I tend to just keep a text file of common cmd line entries around, one of >> which is a simple curl command to create collection1 and the corresponding >> command to remove it. >> >> Something that might make things a bit easier could also be an alternate >> developer 'run example' target that could also fire off a create for >> collection1. >> >> For other cases, I'd think of it like a database example - step one is to >> create a table named foo, not dive in on the built in table1. >> >> - Mark >> >> On Sun Nov 02 2014 at 4:34:57 PM Shawn Heisey <apa...@elyograg.org> wrote: >>> >>> I hope this won't serve to interrupt the momentum for SOLR-3619 and >>> related work, just perhaps influence the direction. What I'm going to >>> relate here probably is no surprise to anyone involved with the effort. >>> >>> In response to a user's question on IRC, I wanted to take their >>> fieldType, incorporate it into the main example on my source code >>> checkout, and fire up the example so I could poke around on the analysis >>> tab. >>> >>> I only had branch_5x, and it was a clean checkout, so I did "svn up" >>> followed by "ant example" and got to work. The first thing I discovered >>> is that there's no longer a conf directory in example/solr/collection1. >>> I poked around for a bit, found what looked like a likely candidate >>> config, and modified the schema.xml. Then I poked around a bit more and >>> learned that "bin/solr start" was what I need to use to get it running. >>> >>> I was surprised to see that when Solr started, there were no cores >>> loaded at all. Thinking about all the discussions around this topic, >>> this makes a lot of sense ... but it does make it hard to implement what >>> I typically use the example for, which is quick tests of small >>> config/schema changes or user-provided scenarios from IRC or the mailing >>> list. >>> >>> I think the README or other documentation should probably cover exactly >>> what to do if your intent is to use collection1, modify it, and poke >>> around. >>> >>> Separately, I noticed that there are a lot of java options used to start >>> the server, including an increase to PermSize. In all my time using >>> Solr, I've never had to change that. Do we have common problems with >>> the new startup script and solr version that require it? >>> >>> Thanks, >>> Shawn >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
