The code can be written against JDBC. But we need to test the DDL and
data types on al the supported DBs
But , which one would we like to ship with Solr as a default option?
H2 looks impressive. the jar (small) is just 667KB and the memory
footprint is small too
--Noble
On Wed, Dec 3, 2008 at 1
check http://www.h2database.com/ in my view the best embedded DB out
there.
from the maker of HSQLDB... is second round.
However, from anything solr, I would hope it would just rely on JDBC.
On Dec 2, 2008, at 12:08 PM, Shalin Shekhar Mangar wrote:
HSQLDB has a limit of upto 8GB of data.
[
https://issues.apache.org/jira/browse/SOLR-284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Harris updated SOLR-284:
--
Attachment: SOLR-284.patch
Changes since my previous upload:
* sync CHANGES.txt with trunk
* test cases
[
https://issues.apache.org/jira/browse/SOLR-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652623#action_12652623
]
Grant Ingersoll commented on SOLR-877:
--
Can you supply as a patch with some simple unit
[
https://issues.apache.org/jira/browse/SOLR-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652603#action_12652603
]
kheechin edited comment on SOLR-877 at 12/2/08 4:12 PM:
-
As a solr-us
[
https://issues.apache.org/jira/browse/SOLR-877?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652603#action_12652603
]
Khee Chin commented on SOLR-877:
As a solr-user who uses this function for auto-complete, I'd
recent wiki updates have be looking at UnInvertedField for the first time
(i haven't been very good at keeping up with commits the last few months)
and i'm wondering about the use of a "static Cache multiValuedFieldCache"
keyed off of SolrIndexSearcher.
Lucene-Java is trying to move away fro
: I've updated the wording - hopefully it's a little clearer now.
Yeah, but SolrFacetingOverview should probably be updated as well.
: counting up terms. This did exist for single valued fields, and now
: also exists for multi-valued fields. The implementation is different
: of course, but I
On Tue, Dec 2, 2008 at 2:32 PM, Chris Hostetter
<[EMAIL PROTECTED]> wrote:
>
> : + This parameter indicates what type of algorithm/method to use when
> faceting a field.
> : +
> : + The {{{enum}}} method was the default (and only) method prior to Solr1.4.
> It enumerates all terms in a field, ca
: + This parameter indicates what type of algorithm/method to use when faceting
a field.
: +
: + The {{{enum}}} method was the default (and only) method prior to Solr1.4.
It enumerates all terms in a field, calculating the set intersection of
documents that match the term with documents that
[
https://issues.apache.org/jira/browse/SOLR-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652442#action_12652442
]
noble.paul edited comment on SOLR-828 at 12/2/08 10:14 AM:
---
The new
I shall try to explain the implementation.
Ideally the backup store should keep all fields of all uncommitted docs.
For committed docs, it must store all the non-stored fields and any
field which is a destination of copyField.
The idea of fetching all the stored fields from DB is not right I
gue
[
https://issues.apache.org/jira/browse/SOLR-828?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652442#action_12652442
]
Noble Paul commented on SOLR-828:
-
The new {{UpdateProcessor}} called ({{UpdateableIndexProc
[
https://issues.apache.org/jira/browse/SOLR-828?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-828:
Description:
This is same as SOLR-139. A new issue is opened so that the UpdateProcessor
approach is highlig
On Tue, Dec 2, 2008 at 12:08 PM, Shalin Shekhar Mangar
<[EMAIL PROTECTED]> wrote:
> HSQLDB has a limit of upto 8GB of data. In Solr, you might want to go beyond
> that without a commit.
Ah, so you only use the DB to store the uncommitted docs so you can
quickly reference their fields?
If that's a
HSQLDB has a limit of upto 8GB of data. In Solr, you might want to go beyond
that without a commit.
On Tue, Dec 2, 2008 at 10:33 PM, Dawid Weiss
<[EMAIL PROTECTED]>wrote:
>
> Isn't HSQLDB an option? Its performance ranges a lot depending on the
> volume of data and queries, but otherwise the lice
Isn't HSQLDB an option? Its performance ranges a lot depending on the volume of
data and queries, but otherwise the license looks BSDish.
http://hsqldb.org/web/hsqlLicense.html
Dawid
On Tue, Dec 2, 2008 at 11:47 AM, Noble Paul നോബിള് नोब्ळ्
<[EMAIL PROTECTED]> wrote:
> OK . Could you guys give some quick feedback on SOLR-828 and SOLR-810
>
> If I get early feedback I may be able to avoid rewrites.
Took a very quick look. Seems like documents should have a version or
revision
OK . Could you guys give some quick feedback on SOLR-828 and SOLR-810
If I get early feedback I may be able to avoid rewrites.
On Tue, Dec 2, 2008 at 10:14 PM, Noble Paul നോബിള് नोब्ळ्
<[EMAIL PROTECTED]> wrote:
> OK . So , I'll stick to JDBC. Derby looks like the best bet
>
> If we must ship it
OK . So , I'll stick to JDBC. Derby looks like the best bet
If we must ship it along w/ Solr it is another 2.6MB jar (embdded
version) with the distro.
On Tue, Dec 2, 2008 at 9:35 PM, Jason Rutherglen
<[EMAIL PROTECTED]> wrote:
> It's mostly dead and synchronizes on reads and writes.
>
> On Tue
Jason Rutherglen wrote:
It's mostly dead and synchronizes on reads and writes.
On Tue, Dec 2, 2008 at 7:46 AM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On Tue, Dec 2, 2008 at 10:12 AM, Andrzej Bialecki <[EMAIL PROTECTED]> wrote:
Please consider using JDBM, now in the Apache incubator,
It does
It's mostly dead and synchronizes on reads and writes.
On Tue, Dec 2, 2008 at 7:46 AM, Yonik Seeley <[EMAIL PROTECTED]> wrote:
> On Tue, Dec 2, 2008 at 10:12 AM, Andrzej Bialecki <[EMAIL PROTECTED]> wrote:
> > Please consider using JDBM, now in the Apache incubator,
>
> It doesn't look like it's
On Tue, Dec 2, 2008 at 10:12 AM, Andrzej Bialecki <[EMAIL PROTECTED]> wrote:
> Please consider using JDBM, now in the Apache incubator,
It doesn't look like it's in the incubator yet... there was interest,
but a proposal was never put on the wiki.
> but with a long
> history at SF.net and wide us
[
https://issues.apache.org/jira/browse/SOLR-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Yonik Seeley updated SOLR-892:
--
Attachment: SOLR-892.patch
This simple patch should fix the boolean encoding issue.
> PHPResponseWriter
[
https://issues.apache.org/jira/browse/SOLR-892?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12652403#action_12652403
]
Yonik Seeley commented on SOLR-892:
---
I don't know PHP, but I was able to verify that boole
Yonik Seeley wrote:
On Mon, Dec 1, 2008 at 11:20 PM, Noble Paul നോബിള് नोब्ळ्
<[EMAIL PROTECTED]> wrote:
BDB-JE does not have a a JDBC driver. It has a java API to read/write.
I just looked at this license - unfortunately it has a GPL like clause:
* 3. Redistributions in any form must be ac
On Mon, Dec 1, 2008 at 11:20 PM, Noble Paul നോബിള് नोब्ळ्
<[EMAIL PROTECTED]> wrote:
> BDB-JE does not have a a JDBC driver. It has a java API to read/write.
I just looked at this license - unfortunately it has a GPL like clause:
* 3. Redistributions in any form must be accompanied by informati
[
https://issues.apache.org/jira/browse/SOLR-892?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steffen Baumgart updated SOLR-892:
--
Affects Version/s: 1.3.1
> PHPResponseWriter fails to serialize boolean vars for spellcheck outpu
PHPResponseWriter fails to serialize boolean vars for spellcheck output
---
Key: SOLR-892
URL: https://issues.apache.org/jira/browse/SOLR-892
Project: Solr
Issue Type: Bug
init-forrest-entities:
[mkdir] Created dir: /tmp/apache-solr-nightly/build
[mkdir] Created dir: /tmp/apache-solr-nightly/build/web
compile-common:
[mkdir] Created dir: /tmp/apache-solr-nightly/build/common
[javac] Compiling 40 source files to /tmp/apache-solr-nightly/build/common
30 matches
Mail list logo
