Processing ActorsController#index (for 24.136.9.221 at 2010-01-20
02:54:48) [GET]
Jan 20, 2010 2:54:48 AM sun.reflect.GeneratedMethodAccessor1 invoke
INFO:
NoMethodError (undefined method `all' for Actor:Class):
app/controllers/actors_controller.rb:7:in `index'
app/controllers/actors_controller.rb:63:in `neo_tx'
:1
Since the refactor is there a new way to write the index action?
def index
@actors = Actor.all.nodes
end
Thanks,
Max
There are two ways of working with relationships:
* undeclared - using the rels method
* declared - using the has_n, has_one, has_list methods
The problem is when you want to use the rels method on declared
relationships - then you might have to prefix the
relationships with the classname, as you described.
The reason for this behaviour can be found here:
http://neo4j.lighthouseapp.com/projects/15548/tickets/92-has_onefrom-using-the-wrong-has_nto
Instead of using the @movie.rels.incoming("Movie#acted_in") you should
use the declared actors method which is
defined in the example: the app/models/movie.rb
class Movie
include Neo4j::NodeMixin
property :title
property :year
# defines a method for traversing incoming acted_in relationships from Actor
has_n(:actors).from(Actor, :acted_in)
end
So try to change
@movie.rels.incoming("Movie#acted_in")
to
@movie.actors
I would be great if you could fix that in the example so that I can
pull from you.
/Andreas
> --
> You received this message because you are subscribed to the Google Groups
> "neo4jrb" group.
> To post to this group, send email to neo...@googlegroups.com.
> To unsubscribe from this group, send email to
> neo4jrb+u...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/neo4jrb?hl=en.
>
Maybe
@movies.actors.rels ?
or should the rels method understand declared relationships as well ?
What do you think ?
How about
@movies.actors.roles
which is available when you declare it with
has_n(:actors).from(Actor, :acted_in).relationship(Role, :roles)
Maybe that's a bit too much magic and it's not clear that roles gives
you relationship object instead of nodes.
It's also possible to let the actors method take an argument (a symbol
or a hash), like:
@movie.actors(:rels).each
I think I prefer Stephens version, it is also easier to implement.
What do you think ?
I have to do some more thinking.
Would also be cool to allow navigation in several relationships like
@movie.actors.agent.friends or
@movie.actors{salary > 100000).agent{:name == 'james'}.movies.each { ...}
or with rels
@movies.actors_rels{role == 'hero'}.agent.each ...
/Andreas
The actors method is generated by the following line:
has_n(:actors).from(Actor, :acted_in)
I would prefer not using the acted_in for accessing relationships. Why
should the user care about if it is incoming or outgoing from a
different class ?
Also, if the user change the acted_in relationship later it would be
more things to change in his code.
Instead, I would prefer only using the actors method and maybe an
actors_rels method so that the knowledge of direction and relationship
can
be abstracted away.
I would also keep the rels method for only low level undeclared
relationships and the generated method (by has_n)
for navigation in declared relationships.
> going with @movies.actors_rels feels backward to me because we are specifying the end node first and then specifying the relationship afterwards.
But does the user want to know the direction (incoming acted_in) of
the relationship when using declared relationships ?
Is it not enough for the user to know that he wants the relationships
from the actors method ?
What do you think ?
class Person include Neo4j::NodeMixin has_n :knows # will generate a knows method for outgoing relationships has_n(:known_by).from(Person, :knows) # will generate a known_by method for incoming knows relationship end
Anybody tempted to implement this ?
I'm not sure about the _by and _by_rels methods.
Why do we need them ?
By using the has_n and has_one there is no need to know the direction
of relationships, or is it ?
Depending on how knows was declared @person.knows and
@person.knows_rels will give is either incoming or outgoing
nodes/relationships.
I have now implemented this feature.
You can now access relationship using both _rels (e.g.
person.friends_rels) and _rel (e.g. person.manager_rel) method.
I implement this feature in the HasN class which means that you can
also access relationships like this:
person.friends.rels
which is the same as person.friends_rels
The only thing missing is now testing and updating the rails example.
@Max: Do you want to fix the rails example ?
I will add another lighthouse ticket on permitting mixing and matching
node and relationship qualifiers
(allow something like @movies.actors_rels{role == 'hero'}.actors{name
== 'mcclane'}.agent_rel{:representation == "north america}.agent.each
...)
/Andreas
The example shows what I did: the property for acted_in which is
named :name is evaluated against :value "name1"; if the condition met,
then the result is collected into some container, and then chained to
the next node.
irb(main):813:0>
actor1.acted_in_rels.condition({:rel_property=>:name,:value=>"name1"})
=> [#<Movie:0x17892d5 @_java_node=#<#<Class:01x1971eb3>:0xeff545
@_wrapper=#<Movie:0x17892d5 ...>>>]
irb(main):814:0>
thanks,
jia
Will add a lighthouse ticket on this
/Andreas
On Feb 7, 11:11 am, Andreas Ronge <andreas.ro...@jayway.se> wrote:
> Great.
> I think it should be a bit similar to filtering nodes in a a has_n
> relationship.
> You can now write
> actor1.acted_in{name == 'jimmy'}.each
> Not sure how much of that code could be reused for filtering relationship
> Btw, the block {name == 'jimmy'} is evaluated in the context of the
> node, that's why one cane write just: name == 'jimmy'
>
> Will add a lighthouse ticket on this
> /Andreas
>