The "userfiles" thing is merely a directory. There's no CRUD API on it. Even if the CRUD API of the file store isn't active in standalone -- I think that doesn't matter. You're left with the <solrhome>/filestore/ dir to put there what you want in standalone mode.
~ David Smiley Apache Lucene/Solr Search Developer http://www.linkedin.com/in/davidwsmiley On Fri, Sep 25, 2020 at 11:00 AM Ishan Chattopadhyaya < [email protected]> wrote: > Standalone isn't supported. > > We need to transition away from the standalone mode and get rid of it > completely. > > On Fri, 25 Sep, 2020, 7:50 pm Jason Gerlowski, <[email protected]> > wrote: > >> I don't know much about the new package/file-store, but it does sound >> like a good replacement for 'userfiles' (which Eric is right- is >> pretty awkward to work with). >> >> My only concerns with using the filestore would be around its >> availability. Is it enabled by default (or will it be in an upcoming >> release)? Does it work in standalone as well as SolrCloud? If the >> answer to those questions are both "yes", then it makes sense to me as >> a replacement on the face of things. >> >> Jason >> >> On Fri, Sep 25, 2020 at 9:39 AM Eric Pugh >> <[email protected]> wrote: >> > >> > +1. I’ve found the user files really useful when doing things with >> streaming, but it’s also awkward to reach to put files into. >> > >> > >> > On Sep 25, 2020, at 8:47 AM, David Smiley <[email protected]> wrote: >> > >> > Yes. And I think it's high time that coreRootDirectory default to >> <solrhome>/something (e.g. "cores") >> > >> > ~ David Smiley >> > Apache Lucene/Solr Search Developer >> > http://www.linkedin.com/in/davidwsmiley >> > >> > >> > On Fri, Sep 25, 2020 at 8:42 AM Alexandre Rafalovitch < >> [email protected]> wrote: >> >> >> >> Would that file store also be under solr.home? Because if it is and >> >> the user can upload core.property into it as well as other things that >> >> core discovery will then load bypassing security.... >> >> >> >> Regards, >> >> Alex. >> >> >> >> On Fri, 25 Sep 2020 at 08:32, David Smiley <[email protected]> wrote: >> >> > >> >> > I'm looking to see that we can deprecate "userfiles" and remove for >> 9.0 >> >> > >> >> > Solr has a "userfiles" directory under Solr home that Jason added in >> some issue relating to streaming expressions accessing a local file. I bet >> only a few of you have even heard of it. I think the "File Store" that >> came along with the package manager obsoletes "userfiles". If you have not >> heard of the file store either, I wouldn't be surprised -- it's new and >> it's name was changed from "package store" last minute, since it's general >> purpose, with "packages" being a directory at the root of the file store >> for packages. It's documented as the "package store" (should be renamed) >> on the package manager internals doc: >> https://lucene.apache.org/solr/guide/8_6/package-manager-internals.html#package-store >> >> > However IMO it's worthy of its own doc page as it's a very useful >> new component of the Solr platform. It can store "user files" (hence >> obsoleting the userfiles dir), ML models, or basically any file that's too >> large to put in ZK. I'd be nice if SolrResourceLoader could resolve >> resources from it -- an issue for another day. That would be another >> avenue of use separate from the configSet. You can already upload single >> files to the file store :-) >> >> > >> >> > ~ David Smiley >> >> > Apache Lucene/Solr Search Developer >> >> > http://www.linkedin.com/in/davidwsmiley >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: [email protected] >> >> For additional commands, e-mail: [email protected] >> >> >> > >> > _______________________ >> > Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 >> | http://www.opensourceconnections.com | My Free/Busy >> > Co-Author: Apache Solr Enterprise Search Server, 3rd Ed >> > This e-mail and all contents, including attachments, is considered to >> be Company Confidential unless explicitly stated otherwise, regardless of >> whether attachments are marked as such. >> > >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >>
