Open ColinFay opened 6 years ago
@ColinFay Apologies for the delay. I would agree that a convenience function to add one element at a time is likely not needed. I think the assumption is that most if not all package users will have some familiarity with Cypher and in this case I think sending the api call is just as straight forward as using a custom function. I could see getting to this level of granularity if there was ever a goal to allow end users to use this package without needing to know Cypher at all.
To chime in, and as someone who tends to put data into neo4j in bulk, you could envision applications with the need to CRUD nodes/relationships and edit constraints when called from something like a Shiny app or an api run through plumber.
Thanks @michaelpawlus and @Btibert3 for your inputs
I think we can assume that future users will be somewhat familiar with cypher, but indeed this could help for newcomers. The "Using Neo4J with R" bookdown we plan on writing will start with a "crash course in cypher", so I hope users will know a little bit about cypher.
Plus : the {cyphersugar} package (currently working on it), will also allow to write code like :
CREATE() %>% node(label = "Person", properties = c("name" = "Colin"))
But you're both right: a create_node function can help beginners (and is not really complex to implement, so why not :) ), and could be used to do some small updates to the data after a bulk import.
I'm wondering if the implementation of
create_nodes
/create_constraint
and such would make sense?Here are why :
Do we really implement one node/relationship at a time at some point ? Given that the package will implement an
as_nodes
from a dataframe, it seems to me that we are more prone to create a bulk of nodes than a single nodeIs
create_nodes("Person", name = "Colin", con_object)
significantly quicker/less verbose thancall_api("CREATE (Person {name : 'Colin'})", con_object)
?What's your take on that ?