Solr
  1. Solr
  2. SOLR-230

make post.jar support better args for using tutorial

    Details

    • Type: New Feature New Feature
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.2
    • Component/s: update
    • Labels:
      None

      Description

      SOLR-86 create post.jar which eliminated the need for post.sh ... but as noticed in
      SOLR-164 there are still some cases in the tutorial that require direct use of curl (deleting) and there are some nice things about post.sh that post.jar doesn't support (defaulting the URL)

      this issue is to tackle some of the ideas Bertrand and I posted as a comment in SOLR-86 after it was resolved....

      Bertrand Delacretaz [19/Feb/07 12:35 AM] ...
      Considering the tutorial examples (http://lucene.apache.org/solr/tutorial.html), it'd be useful to allow this to POST its standard input, or the contents of a command-line parameter: ...

      Hoss Man [19/Feb/07 11:50 AM]
      yeah ... i think we should hardcode http://localhost:8983/solr/update with a possible override by system prop, then add either a command line switch other another system prop indicating to use the command line as filenames or as raw data, and another op for stdin.

      java -jar -Ddata=files post.jar *.xml
      java -jar post.jar *.xml ... data=files being the default
      echo "<delete><query>name:DDR</query></delete>" | java -jar -Ddata=stdin post.jar
      cat *.xml | java -jar -Ddata=stdin post.jar
      java -jar -Ddata=args post.jar "<delete><query>name:DDR</query></delete>"
      java -jar -Durl=http://localhost:8983/solr/update post.jar *.xml

        Issue Links

          Activity

          Hide
          Hoss Man added a comment -

          patch that tackles all of these changes ... modifies SimplePostTool a well as the tutorial.

          note two small differences between what i proposed and what I implemented...
          1) "cat *.xml | post -Ddata=stdin -jar post.jar" does not work because when reading from stdin we have 1 and only one stream to post, and the examples files themselves contain the <add> blocks. "cat *.xml | post -Ddata=stdin -jar post.jar" does work however
          2) i added a "commit" system prop and defaulted it to "yes" ... this is needed because when deleting in the tutorial it wants to show off the pending dleetes and the fact that the doc is still there until you commit.

          for what it's worth there is now also simple support for "-help" option, but i don't know if we should advertise it ... if anyone is using post.jar beyond what is described in theetutorial, they should relaly look at the code itself.

          Show
          Hoss Man added a comment - patch that tackles all of these changes ... modifies SimplePostTool a well as the tutorial. note two small differences between what i proposed and what I implemented... 1) "cat *.xml | post -Ddata=stdin -jar post.jar" does not work because when reading from stdin we have 1 and only one stream to post, and the examples files themselves contain the <add> blocks. "cat *.xml | post -Ddata=stdin -jar post.jar" does work however 2) i added a "commit" system prop and defaulted it to "yes" ... this is needed because when deleting in the tutorial it wants to show off the pending dleetes and the fact that the doc is still there until you commit. for what it's worth there is now also simple support for "-help" option, but i don't know if we should advertise it ... if anyone is using post.jar beyond what is described in theetutorial, they should relaly look at the code itself.
          Hide
          Hoss Man added a comment -

          baring objection, i'll plan on committing this later this week.

          Show
          Hoss Man added a comment - baring objection, i'll plan on committing this later this week.
          Hide
          Carsten added a comment -

          Being from the unix fraction:
          Why is there a need for "-Ddata=stdin" ?
          Just make it read from stdin if no arguments are given.
          Good old unix tradition.

          And by the way: Why would you use system properties to pass parameters instead of simply using a parameter like

          java -jar post.jar -url http://localhost:8983/solr/update *.xml
          java -jar post.jar -data "<delete><query>name:DDR</query></delete>"

          Just my EUR 0.02.

          Show
          Carsten added a comment - Being from the unix fraction: Why is there a need for "-Ddata=stdin" ? Just make it read from stdin if no arguments are given. Good old unix tradition. And by the way: Why would you use system properties to pass parameters instead of simply using a parameter like java -jar post.jar -url http://localhost:8983/solr/update *.xml java -jar post.jar -data "<delete><query>name:DDR</query></delete>" Just my EUR 0.02.
          Hide
          Hoss Man added a comment -

          To answer both questions: i did it that way just to try and keep the code simple and explicit. i figured using system props would help make the execution examples in the tutorial self documenting, while keeping the simple uses cases very simple, and eliminating the need for any complex getopt style argv parsing.

          Show
          Hoss Man added a comment - To answer both questions: i did it that way just to try and keep the code simple and explicit. i figured using system props would help make the execution examples in the tutorial self documenting, while keeping the simple uses cases very simple, and eliminating the need for any complex getopt style argv parsing.
          Hide
          Hoss Man added a comment -

          Committed revision 541046.

          Show
          Hoss Man added a comment - Committed revision 541046.

            People

            • Assignee:
              Hoss Man
              Reporter:
              Hoss Man
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development