Thanks for the information Michael
That is really unfortunate. I hope this functionality will be introduced
later. I really like the concept of labels.
Wojtek
On Thursday, March 6, 2014 6:25:18 PM UTC+1, Michael Hunger wrote:
>
> Hi Wojtek,
>
> unfortunately labels are not returned from any of the endpoints with the
> nodes automatically, so they have to be fetched separately.
>
> Sorry for that.
>
> You can return to the Indexed type-representation strategy with using this
> config:
>
> <bean id="typeRepresentationStrategyFactory"
> class="org.springframework.data.neo4j.support.typerepresentation.TypeRepresentationStrategyFactory">
> <constructor-arg index="0" ref="graphDatabase"/>
> <constructor-arg index="1" value="Indexed"/>
> </bean>
>
> <neo4j:config storeDirectory="graph.db"
> base-package="com.example.domain,com.example.domain2"/>
> <neo4j:repositories base-package="com.example.repositories"/>
>
>
>
> Am 06.03.2014 um 18:07 schrieb Wojtek Wysocki
> <wojtek.w...@gmail.com<javascript:>
> >:
>
> Hi
>
> I am the author of mentioned stackoverflow question (and BTW new to this
> group)
>
> I understand the need for labels to be fetched but how it is handled now
> is just a show stopper for me.
> We are talking about tens of additional REST requests which increase
> method run time significantly.
>
> some questions
> - can labels be fetched with node data? I don't know why it is not so
> already since labels are such crucial information for nodes. Is it
> something we can expect to be implemented in future releases?
> - can this data be at least fetched in bulk for all nodes in returned list?
> side question
> - if this implementation is here to stay can I go back to previous
> functionality where class name was stored in the node property without
> going back to some previous releases?
>
> Thanks
> Wojtek
>
> On Thursday, March 6, 2014 4:36:15 PM UTC+1, Michael Hunger wrote:
>>
>> Yep,
>>
>> my question was how would you imagine it to be configured.
>>
>> Michael
>>
>> Am 06.03.2014 um 16:35 schrieb Gwendal Mousset <gwendal...@gmail.com>:
>>
>> Thanks Michael,
>>
>> I understand the need to check the label directly on db. I hadn't think
>> about inheritance.
>> Do you think this check could became optional (with configuration) to
>> choose between fully operational inheritance and better performances ?
>>
>>
>> Gwendal
>>
>> On Thursday, March 6, 2014 4:13:51 PM UTC+1, Michael Hunger wrote:
>>>
>>> Imagine you have a class hierarchy like Person and Developer
>>>
>>> And you have a person repo but the nodes in the db are actually
>>> developers.
>>>
>>> Then you would want to get the correct instances back (Developer) but
>>> requested target type is Person
>>>
>>> How would you imagine to configure it so that it doesn't look what the
>>> node is in the graph but just takes the requested type?
>>>
>>>
>>> Michael
>>>
>>> Am 06.03.2014 um 15:54 schrieb Gwendal Mousset <gwendal...@gmail.com>:
>>>
>>> Hi everyone,
>>>
>>> I use neo4j 2.0.1 with rest api.
>>> To obtain better performances in my webapp, I refactor my code by using
>>> @QueryResult objects and do more "big" requests instead of many small
>>> requests.
>>> But the logs show me than each time I get an object from the query
>>> result, a request is sent:
>>>
>>> 2014-03-06 15:15:43,208 - DEBUG: SpringRestCypherQueryEngine - Executing
>>> remote cypher query: match (n) where id(n)={nodeId} return labels(n) as
>>> labels params {nodeId=509}
>>>
>>> This request only get the labels of a node, and it seems there is no
>>> cache, the request can be sent several time for a same node.
>>> On a collection, dozens of requests are sent...
>>>
>>> I seek in SDN code what are the reason, and i found
>>> Neo4jEntityConverterImpl :
>>>
>>> public <R extends T> R read(Class<R> requestedType, S source,
>>> MappingPolicy mappingPolicy, final Neo4jTemplate template) {
>>>
>>> // 1) source -> type alias
>>>
>>> // 2) type alias -> type
>>>
>>> // 3) check for subtype matching / enforcement
>>>
>>> final TypeInformation<R> requestedTypeInformation =
>>> requestedType == null ? null : ClassTypeInformation.from(requestedType);
>>>
>>> final TypeInformation<? extends R> targetType =
>>> typeMapper.readType(source,
>>> requestedTypeInformation); <-- causes get labels request
>>>
>>>
>>> ...... //
>>>
>>> }
>>>
>>> If I correctly understand, this code determines which classes must be
>>> instantiate. But what i don't understand is that
>>> requestedTypeInformation and targetType have the same value.
>>> So would it be possible to bypass the db check and only take
>>> the requestedTypeInformation value ?
>>>
>>> I found a quite similar question on stakoverflow:
>>> http://stackoverflow.com/questions/22209220/unnecessary-additional-label-requests-for-nodes
>>>
>>> Thanks
>>>
>>> --
>>> You received this message because you are subscribed to the Google
>>> Groups "Neo4j" group.
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to neo4j+un...@googlegroups.com.
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>>
>>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Neo4j" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to neo4j+un...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
> --
> You received this message because you are subscribed to the Google Groups
> "Neo4j" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to neo4j+un...@googlegroups.com <javascript:>.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Neo4j" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to neo4j+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
