Re: How to use TZ parameter in a query

2016-04-06 Thread Bogdan Marinescu

I understand. Would be nice though :)

Thanks.

On 04/06/2016 11:26 AM, jimi.hulleg...@svensktnaringsliv.se wrote:

I think that this parameter is only used to interpret the dates provided in the 
query, like query filters. At least that is how I interpret the wiki text. Your 
interpretation makes more sense in general though, it would be nice if it was 
possible to modify the timezone for both the query and the result.

/Jimi

-Original Message-
From: Bogdan Marinescu [mailto:bogdan.marine...@awinta.com]
Sent: Wednesday, April 6, 2016 11:20 AM
To: solr-user@lucene.apache.org
Subject: How to use TZ parameter in a query

Hi,

According to the wiki
https://wiki.apache.org/solr/CoreQueryParameters#TZ I can use the TZ param to 
specify the timezone.
I tried to make a query and put in the raw section TZ=Europe/Berlin or any 
other found in https://en.wikipedia.org/wiki/List_of_tz_database_time_zones but 
no luck. The date that I get back is still in UTC format.

Any ideas what I'm doing wrong?

Thanks




How to use TZ parameter in a query

2016-04-06 Thread Bogdan Marinescu

Hi,

According to the wiki 
https://wiki.apache.org/solr/CoreQueryParameters#TZ I can use the TZ 
param to specify the timezone.
I tried to make a query and put in the raw section TZ=Europe/Berlin or 
any other found in 
https://en.wikipedia.org/wiki/List_of_tz_database_time_zones but no 
luck. The date that I get back is still in UTC format.


Any ideas what I'm doing wrong?

Thanks


Re: Cannot talk to ZooKeeper - Updates are disabled.

2016-02-19 Thread Bogdan Marinescu

And is there a workaround?
That jira issue is full of Zookeeper problems. Doubt it it will be 
solved anytime soon.



On 02/19/2016 04:38 PM, Binoy Dalal wrote:

There's a JIRA ticket regarding this, and as of yet is unresolved.
https://issues.apache.org/jira/browse/SOLR-3274

On Fri, Feb 19, 2016 at 2:11 PM Bogdan Marinescu <
bogdan.marine...@awinta.com> wrote:


Hi,

  From time to time I get org.apache.solr.common.SolrException: Cannot
talk to ZooKeeper - Updates are disabled.

Most likely when sol'r receives a lot of documents. My question is, why
is this happening and how to get around it ?

Stacktrace:
org.apache.solr.common.SolrException: Cannot talk to ZooKeeper - Updates
are disabled.
  at

org.apache.solr.update.processor.DistributedUpdateProcessor.zkCheck(DistributedUpdateProcessor.java:1482)
  at

org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:664)
  at
org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:250)
  at
org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:177)
  at

org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:98)
  at

org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
  at

org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)
  at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
  at
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)
  at
org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
  at

org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
  at

org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
  at

awinta.mdm.solr.filter.AuraSolrDispatchFilter.doFilter(AuraSolrDispatchFilter.java:58)
  at

org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
  at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
  at

org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
  at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:553)
  at

org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
  at

org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
  at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
  at

org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
  at

org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
  at

org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
  at

org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
  at

org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
  at

org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
  at org.eclipse.jetty.server.Server.handle(Server.java:497)
  at
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
  at
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
  at
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
  at

org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
  at

org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)
  at java.lang.Thread.run(Thread.java:745)

Thanks

Bogdan Marinescu





Cannot talk to ZooKeeper - Updates are disabled.

2016-02-19 Thread Bogdan Marinescu

Hi,

From time to time I get org.apache.solr.common.SolrException: Cannot 
talk to ZooKeeper - Updates are disabled.


Most likely when sol'r receives a lot of documents. My question is, why 
is this happening and how to get around it ?


Stacktrace:
org.apache.solr.common.SolrException: Cannot talk to ZooKeeper - Updates 
are disabled.
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.zkCheck(DistributedUpdateProcessor.java:1482)
at 
org.apache.solr.update.processor.DistributedUpdateProcessor.processAdd(DistributedUpdateProcessor.java:664)
at 
org.apache.solr.handler.loader.XMLLoader.processUpdate(XMLLoader.java:250)
at 
org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:177)
at 
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:98)
at 
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
at 
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:143)

at org.apache.solr.core.SolrCore.execute(SolrCore.java:2064)
at 
org.apache.solr.servlet.HttpSolrCall.execute(HttpSolrCall.java:654)

at org.apache.solr.servlet.HttpSolrCall.call(HttpSolrCall.java:450)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:227)
at 
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:196)
at 
awinta.mdm.solr.filter.AuraSolrDispatchFilter.doFilter(AuraSolrDispatchFilter.java:58)
at 
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1652)
at 
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:585)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
at 
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:553)
at 
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:223)
at 
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1127)
at 
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:515)
at 
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:185)
at 
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1061)
at 
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
at 
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:215)
at 
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:110)
at 
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)

at org.eclipse.jetty.server.Server.handle(Server.java:497)
at 
org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:310)
at 
org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:257)
at 
org.eclipse.jetty.io.AbstractConnection$2.run(AbstractConnection.java:540)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:635)
at 
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:555)

at java.lang.Thread.run(Thread.java:745)

Thanks

Bogdan Marinescu


Re: Nested Docs issue

2015-12-10 Thread Bogdan Marinescu
I've already implemented something similar to what you've said. Setting 
the _root_ into the document and for safety double checking that I don't 
have the same ID twice.


I'm interested in the workaround.

Thanks

On 12/10/2015 10:24 AM, Mikhail Khludnev wrote:

I want to fix it in scope of https://issues.apache.org/jira/browse/SOLR-5211
and hope it will be released in 5.5.
It will *copy* $UniqueKey into "_root_" aways (regardless of having a
child).
Thus we will have $UniqueKey really unique. Overriding update will work.
But deleteByID won't work out-of-the-box for parents with child. And
deleteByQuery should be tweaked to handle blocks.
I almost done it in earlier patch.
https://issues.apache.org/jira/secure/attachment/12739197/SOLR-7606.patch
Is it really urgent for you? I'm asking because there is an easy
workaround, despite it seems odd overall.


On Thu, Dec 10, 2015 at 10:41 AM, Bogdan Marinescu <
bogdan.marine...@awinta.com> wrote:


Any suggestions about this ?


On 12/04/2015 08:26 AM, Bogdan Marinescu wrote:


Hi Mikhail,

I would expect the same behaviour as for a database. Meaning if I have a
field declared as an uniqueKey, then there should only be one document with
that key, regardless if it has a child or not.

If you add the childless document first and afterwards the child, then
sol'r should append the child to the already existing document (or rather
delete the existing one as the new one has newer data).

It's weird because when I query sol'r for that ID, I get two documents
when I am only expecting one.
I could do a sort of 'workaround' logic where I would always pick the one
with children but I think better would be to fix this in sol'r.

Regarding your issue SOLR-5211 <
https://issues.apache.org/jira/browse/SOLR-5211>. If a document has
children and you update the parent as childless or in fact delete the
parent altogether, then the child documents should also be deleted.

I've faced this problem where I was just deleting the parent by id and I
had lots of orphan documents just laying around.

Regards,
Bogdan Marinescu

On 12/03/2015 06:26 PM, Mikhail Khludnev wrote:


Hello Bogdan,
You described how it works now. That's how it was implemented. And I can
explain why it was done so.

Could you please describe the expected behavior for you?

Notice, I want to enforce nested (block) behavior always in scope of
https://issues.apache.org/jira/browse/SOLR-5211. So, the fields
assigned to
parent with child and childless single doc will be the same. So, far it's
not clear how to amend  semantic.

On Thu, Dec 3, 2015 at 6:35 PM, Bogdan Marinescu <
bogdan.marine...@awinta.com> wrote:

Hi,

I have a problem with nested docs. If I create a document with id: 1 and
fieldA:sometext and then add it to sol'r, I get one doc in sol'r.

Afterwards if I add a child/nested doc to this document I additionally
get
a _root_:1 to the document but the problem is I now have two documents
with
the same ID (id: 1) in sol'r, one with _root_ and the child/nested doc
and
one without it.

Any ideas why this happens?
Any ideas how to avoid this?

Thanks,












Re: Nested Docs issue

2015-12-10 Thread Bogdan Marinescu

So you mean to write my own script update processor which would do that ?


On 12/10/2015 11:51 AM, Mikhail Khludnev wrote:

On Thu, Dec 10, 2015 at 1:26 PM, Bogdan Marinescu <
bogdan.marine...@awinta.com> wrote:


Problem is I was manually exporting data from a database and converting it
into sol'r docs and writing it to sol'r. No checks were performed if the
converted doc had children or not so I can't really tell if I was doing it
in this order or reversed (first the parent and child and then only the
childless parent).


Empty child doc can be added into childless parent by
http://wiki.apache.org/solr/ScriptUpdateProcessor.



I'm not entirely sure that sol'r would append the child to the already
existing parent but I can check that out.

As for the delete, I'm using deleteByQuery(_root_:parentID). This works
fine because the id of the parent is placed in the _root_ of the children.

I wouldn't use the child query as that performs a ToBlockJoinQuery and
I've had problems with that before (if you recall SOLR-6700 <
https://issues.apache.org/jira/browse/SOLR-6700>)

I'll try your workaround suggestion and hopefully this will be fixed so I
don't have to worry about the order I add the parents and children to sol'r
:)

Thanks



On 12/10/2015 11:14 AM, Mikhail Khludnev wrote:


On Thu, Dec 10, 2015 at 12:38 PM, Bogdan Marinescu <
bogdan.marine...@awinta.com> wrote:

I'm interested in the workaround.
If you add the childless document first and afterwards the child, then


sol'r should append the child to the already existing document (or rather
delete the existing one as the new one has newer data).

I'd suggest to add empty child doc into every empty parent.

I've faced this problem where I was just deleting the parent by id and I


had lots of orphan documents just laying around.

deleteByQuery should be amended :999 should be turned to

_root_:999, the you need to do instead of deleteById.
If you have deleteByQuery(Brand:Nike) (matching parents), it needs to be
turned to deleteByQuery(Brand:Nike {!child of=parent:true}Brand:Nike)








Re: Nested Docs issue

2015-12-10 Thread Bogdan Marinescu
Problem is I was manually exporting data from a database and converting 
it into sol'r docs and writing it to sol'r. No checks were performed if 
the converted doc had children or not so I can't really tell if I was 
doing it in this order or reversed (first the parent and child and then 
only the childless parent).


I'm not entirely sure that sol'r would append the child to the already 
existing parent but I can check that out.


As for the delete, I'm using deleteByQuery(_root_:parentID). This works 
fine because the id of the parent is placed in the _root_ of the children.


I wouldn't use the child query as that performs a ToBlockJoinQuery and 
I've had problems with that before (if you recall SOLR-6700 
<https://issues.apache.org/jira/browse/SOLR-6700>)


I'll try your workaround suggestion and hopefully this will be fixed so 
I don't have to worry about the order I add the parents and children to 
sol'r :)


Thanks


On 12/10/2015 11:14 AM, Mikhail Khludnev wrote:

On Thu, Dec 10, 2015 at 12:38 PM, Bogdan Marinescu <
bogdan.marine...@awinta.com> wrote:


I'm interested in the workaround.


If you add the childless document first and afterwards the child, then

sol'r should append the child to the already existing document (or rather
delete the existing one as the new one has newer data).


I'd suggest to add empty child doc into every empty parent.

I've faced this problem where I was just deleting the parent by id and I

had lots of orphan documents just laying around.


deleteByQuery should be amended :999 should be turned to
_root_:999, the you need to do instead of deleteById.
If you have deleteByQuery(Brand:Nike) (matching parents), it needs to be
turned to deleteByQuery(Brand:Nike {!child of=parent:true}Brand:Nike)





Re: Nested Docs issue

2015-12-09 Thread Bogdan Marinescu

Any suggestions about this ?

On 12/04/2015 08:26 AM, Bogdan Marinescu wrote:

Hi Mikhail,

I would expect the same behaviour as for a database. Meaning if I have 
a field declared as an uniqueKey, then there should only be one 
document with that key, regardless if it has a child or not.


If you add the childless document first and afterwards the child, then 
sol'r should append the child to the already existing document (or 
rather delete the existing one as the new one has newer data).


It's weird because when I query sol'r for that ID, I get two documents 
when I am only expecting one.
I could do a sort of 'workaround' logic where I would always pick the 
one with children but I think better would be to fix this in sol'r.


Regarding your issue SOLR-5211 
<https://issues.apache.org/jira/browse/SOLR-5211>. If a document has 
children and you update the parent as childless or in fact delete the 
parent altogether, then the child documents should also be deleted.


I've faced this problem where I was just deleting the parent by id and 
I had lots of orphan documents just laying around.


Regards,
Bogdan Marinescu

On 12/03/2015 06:26 PM, Mikhail Khludnev wrote:

Hello Bogdan,
You described how it works now. That's how it was implemented. And I can
explain why it was done so.

Could you please describe the expected behavior for you?

Notice, I want to enforce nested (block) behavior always in scope of
https://issues.apache.org/jira/browse/SOLR-5211. So, the fields 
assigned to
parent with child and childless single doc will be the same. So, far 
it's

not clear how to amend  semantic.

On Thu, Dec 3, 2015 at 6:35 PM, Bogdan Marinescu <
bogdan.marine...@awinta.com> wrote:


Hi,

I have a problem with nested docs. If I create a document with id: 1 
and

fieldA:sometext and then add it to sol'r, I get one doc in sol'r.

Afterwards if I add a child/nested doc to this document I 
additionally get
a _root_:1 to the document but the problem is I now have two 
documents with
the same ID (id: 1) in sol'r, one with _root_ and the child/nested 
doc and

one without it.

Any ideas why this happens?
Any ideas how to avoid this?

Thanks,











Re: Nested Docs issue

2015-12-03 Thread Bogdan Marinescu

Hi Mikhail,

I would expect the same behaviour as for a database. Meaning if I have a 
field declared as an uniqueKey, then there should only be one document 
with that key, regardless if it has a child or not.


If you add the childless document first and afterwards the child, then 
sol'r should append the child to the already existing document (or 
rather delete the existing one as the new one has newer data).


It's weird because when I query sol'r for that ID, I get two documents 
when I am only expecting one.
I could do a sort of 'workaround' logic where I would always pick the 
one with children but I think better would be to fix this in sol'r.


Regarding your issue SOLR-5211 
<https://issues.apache.org/jira/browse/SOLR-5211>. If a document has 
children and you update the parent as childless or in fact delete the 
parent altogether, then the child documents should also be deleted.


I've faced this problem where I was just deleting the parent by id and I 
had lots of orphan documents just laying around.


Regards,
Bogdan Marinescu

On 12/03/2015 06:26 PM, Mikhail Khludnev wrote:

Hello Bogdan,
You described how it works now. That's how it was implemented. And I can
explain why it was done so.

Could you please describe the expected behavior for you?

Notice, I want to enforce nested (block) behavior always in scope of
https://issues.apache.org/jira/browse/SOLR-5211. So, the fields assigned to
parent with child and childless single doc will be the same. So, far it's
not clear how to amend  semantic.

On Thu, Dec 3, 2015 at 6:35 PM, Bogdan Marinescu <
bogdan.marine...@awinta.com> wrote:


Hi,

I have a problem with nested docs. If I create a document with id: 1 and
fieldA:sometext and then add it to sol'r, I get one doc in sol'r.

Afterwards if I add a child/nested doc to this document I additionally get
a _root_:1 to the document but the problem is I now have two documents with
the same ID (id: 1) in sol'r, one with _root_ and the child/nested doc and
one without it.

Any ideas why this happens?
Any ideas how to avoid this?

Thanks,








Nested Docs issue

2015-12-03 Thread Bogdan Marinescu

Hi,

I have a problem with nested docs. If I create a document with id: 1 and 
fieldA:sometext and then add it to sol'r, I get one doc in sol'r.


Afterwards if I add a child/nested doc to this document I additionally 
get a _root_:1 to the document but the problem is I now have two 
documents with the same ID (id: 1) in sol'r, one with _root_ and the 
child/nested doc and one without it.


Any ideas why this happens?
Any ideas how to avoid this?

Thanks,