available to the general
> public. Is there any URL where they post their nightly build?
>
> Thanks in advance
> Rajesh Panneerselvam
>
> From: Mikhail Khludnev [via Lucene] [mailto:
> ml-node+s472066n4174700...@n3.nabble.com]
> Sent: 17-Dec-14 15:05
> To: Rajesh Panneers
On 12/31/2014 12:19 AM, Rajesh wrote:
> Is there a way to get the trunk and I can update the same patch to check this
> functionality. If so, where can I get the trunk build?
http://wiki.apache.org/solr/HowToContribute#Getting_the_source_code
You will need a number of software components, includi
Rajesh,
it seems you need the trunk to apply patch on. my favorite way to do this
is
https://github.com/apache/lucene-solr/
Have a good hack!
On Wed, Dec 31, 2014 at 10:19 AM, Rajesh wrote:
> Is there a way to get the trunk and I can update the same patch to check
> this
> functionality. If so,
Is there a way to get the trunk and I can update the same patch to check this
functionality. If so, where can I get the trunk build?
--
View this message in context:
http://lucene.472066.n3.nabble.com/Join-in-SOLR-tp4173930p4176678.html
Sent from the Solr - User mailing list archive at Nabble.c
On 12/30/2014 11:44 PM, Rajesh wrote:
> Oh! Thanks Mikhail. But I could see a comment in that JIRA, above your
> comment which is from Thomas champagne that the patch was committed to
> current trunk. Is it not for this issue Mikhail?
The message from Thomas Champagne indicates that he updated t
+s472066n4176668...@n3.nabble.com]
Sent: 31-Dec-14 11:52
To: Rajesh Panneerselvam
Subject: Re: Join in SOLR
Rajesh,
Nohow. Jira is still open, the patch wasn't committed anywhere.
On Wed, Dec 31, 2014 at 8:27 AM, Rajesh <[hidden
email]>
wrote:
> Mikhail,
>
> How can I get a nightly bui
e general
> public. Is there any URL where they post their nightly build?
>
> Thanks in advance
> Rajesh Panneerselvam
>
> From: Mikhail Khludnev [via Lucene] [mailto:
> ml-node+s472066n4174700...@n3.nabble.com]
> Sent: 17-Dec-14 15:05
> To: Rajesh Panneerselvam
> Subject
ucene]
[mailto:ml-node+s472066n4174700...@n3.nabble.com]
Sent: 17-Dec-14 15:05
To: Rajesh Panneerselvam
Subject: Re: Join in SOLR
On Wed, Dec 17, 2014 at 11:51 AM, Rajesh Panneerselvam <
[hidden email]> wrote:
>
> Yes Mikhail. This is what I want exactly. My sub-entities should be
> add
ime soon?
>
Rajesh, it's a question to committers, you can leave a comment and/or vote
for an issue.
>
>
> Thanks
>
> Rajesh Panneerselvam
>
>
>
> *From:* Mikhail Khludnev [mailto:mkhlud...@griddynamics.com]
> *Sent:* 17-Dec-14 12:43
> *To:* Rajesh Pa
Thanks Mikhail. As per what you have mentioned can I get a list of sub
entities with this new Zipper join. Because in existing DIH I'm getting a
list for individual fields of the sub entities.
And also, I've not found DIH 5 jar anywhere. Is it still in development.
--
View this message in con
On Fri, Dec 12, 2014 at 5:31 PM, Shawn Heisey wrote:
> Using a database view that does the JOIN on the server side is pretty
> much guaranteed to have far better performance. Database software is
> very good at doing joins efficiently when proper DB indexes are
> available ... the dataimport han
On 12/12/2014 5:16 AM, Tomoko Uchida wrote:
> I cannot find out your table structure and Solr schema,
> but if your requirement is too complex to handle by DIH, you could handle
> it by rich database functionality.
>
> I think creating a database view is good choice...
>
> (Of course, other exper
I cannot find out your table structure and Solr schema,
but if your requirement is too complex to handle by DIH, you could handle
it by rich database functionality.
I think creating a database view is good choice...
(Of course, other experts may have ideas using DIH?)
2014-12-12 20:43 GMT+09:0
Yes. two entities are child for the first one. I've gone through the link.
But what I can get out of the configuration given in that link is, I could
get an array for all the individual fields defined in the sub-entities.
For. e.g if my sub-entity has 3 fields name, id, desc. I'm getting a list
for
Thank you for config information.
Three tables have relation (by foreign key) ?
You might want to have one nested tag in rather than 3
one in .
By using nested tag, you may able to merge tables *before*
importing them to Solr. All works done by SQL.
You have already seen this wiki? If not, ex
Thanks for your reply Tomoko. My data-config file looks like the below.
Each entity represents a table in DB. Now, If I want to join these three
tables, can I make use of the SOLR join functionality..
--
View this message in context:
http://lucene.472066.n3.nabble.com/Join-in-SOLR-
Hi,
I cannot guess what is 'entities' in your context, but do you want some
kind of join functionality like RDBs on Solr?
Basically, Solr is not "relational". So at first, you should consider
denormalize your RDB tables to one table/view (or issue SQL JOIN query in
DIH) to import data to Solr.
If
Please read:
http://wiki.apache.org/solr/UsingMailingLists
and the contained link:
http://catb.org/~esr/faqs/smart-questions.html
On Tue, May 13, 2014 at 12:03 AM, Kamal Kishore
wrote:
> NO reply from anybody..seems strange ?
>
>
> On Fri, May 9, 2014 at 9:47 AM, Kamal Kishore
> wrote:
>
>> Any
There are two previous threads in the list that i think can help you,
http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201405.mbox/%3c1398929537117-4134045.p...@n3.nabble.com%3E
http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201404.mbox/%3c20140403114242.horde.epx2xawezs3mvmt
You really have to provide more detail here.
bq: Moreover, solr is not allowing to get data from both the core.
What do you mean? the second core is unavailable? Solr joins
do not return data from the "from" table. I really suggest you
try denormalizing the data first, don't try to use Solr like
Probably because we answered a nearly identical request yesterday. It had items
in one core and counts in a different. Please read all the responses to this
e-mail.
http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201405.mbox/browser
Specifically, these responses:
http://mail-archives
Any updates guys ?
On Thu, May 8, 2014 at 2:05 PM, Kamal Kishore
wrote:
> Dear Team,
>
> I have two solr cores. One containing products information and second has
> customers points. I am looking at solr join to query on first product core
> & boost the results based on customer points in second
NO reply from anybody..seems strange ?
On Fri, May 9, 2014 at 9:47 AM, Kamal Kishore
wrote:
> Any updates guys ?
>
>
> On Thu, May 8, 2014 at 2:05 PM, Kamal Kishore > wrote:
>
>> Dear Team,
>>
>> I have two solr cores. One containing products information and second has
>> customers points. I am
Hello!
If you talk about this:
https://issues.apache.org/jira/browse/SOLR-2272 than it is only
available since 4.0-alpha.
--
Regards,
Rafał Kuć
Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch - ElasticSearch
> Hi. I have read there is "join" functionality in Solr 4 beta.
> Is there
I'm quite open to NOT having a JOIN in Solr if flattening the model
still provides the querying capability desired. I've not fully
followed the specifics that Yonik has mentioned on this thread, but
it certainly is the case that denormalizing/flattening our domain
does not exactly lend its
oops!!! I meant to reply directly to Brian - an old friend of mine
from graduate school...
next time I'll check the reply-to button more closely.
I share my dream with Ryan. My dream API looks like this, sticking
with the artist/track metaphor, in which we have metadata, say the
...
you share my dream! thats amazing!
I really hope eric persists with the JOIN direction... (its would be
great to get the Lucene in Action guys working on
On 2/3/07, Walter Underwood <[EMAIL PROTECTED]> wrote:
We would never use JOIN. We denormalize for speed. Not a big deal.
I'm looking at an application where speed is not the only concern. If
I can remove the need for a 'normalized' and 'denormalized' form it
would be a HUGE win. Essentially
On Feb 3, 2007, at 4:54 PM, Walter Underwood wrote:
We would never use JOIN. We denormalize for speed. Not a big deal.
So out of curiosity then, what would your design be for indexing
"objects" which have attributes that frequently change and the
quicker you get that reflected to users the
We would never use JOIN. We denormalize for speed. Not a big deal.
wunder
==
Search Guru, Netflix
On 2/3/07 11:16 AM, "Brian Whitman" <[EMAIL PROTECTED]> wrote:
> On Feb 2, 2007, at 4:46 PM, Ryan McKinley wrote:
>
>> I would LOVE to see a JOIN in SOLR.
>>
>> I have an index of artists, albums
30 matches
Mail list logo
