[Neo4j] Re: Any plans for an optional schema?
Wow, I'm surprised Structr didn't turn up in any of my previous google searches. I need to do further research, but on an initial glance, this might look to do what I've actually spent numerous hours trying to do with custom rolled code. Thanks for the hat tip! -Jason On Wednesday, July 16, 2014 4:28:54 PM UTC-4, Jason Gillman Jr. wrote: I was just wondering if the ability to utilize a schema of sorts was on the road map. When I say schema, I'm thinking more along the lines of relational constraints. Let's use the following simple example. We have the following types of entities represented by node labels (:`Server`) (:`Switch`) (:`Physical Interface`) Then we would want to enforce the following relations (I would think these restrictions would seem intuitive): (:`Server`)-[:`Contains`]-(:`Physical Interface`) (:`Switch`)-[:`Contains`]-(:`Physical Interface`) (:`Physical Interface`)-[:`Connects`]-(:`Physical Interface`) Basically, to ensure data consistency without having to build it into an application, we would want it so that Neo4j would not allow, for example, a Server to connect to another Server, or a Switch, nor would we want to make a Physical Interface contain a Server. Is something like this in the plans? Of course the use of these constraints would be completely optional. Thanks! -Jason -- 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/d/optout.
[Neo4j] Any plans for an optional schema?
I was just wondering if the ability to utilize a schema of sorts was on the road map. When I say schema, I'm thinking more along the lines of relational constraints. Let's use the following simple example. We have the following types of entities represented by node labels (:`Server`) (:`Switch`) (:`Physical Interface`) Then we would want to enforce the following relations (I would think these restrictions would seem intuitive): (:`Server`)-[:`Contains`]-(:`Physical Interface`) (:`Switch`)-[:`Contains`]-(:`Physical Interface`) (:`Physical Interface`)-[:`Connects`]-(:`Physical Interface`) Basically, to ensure data consistency without having to build it into an application, we would want it so that Neo4j would not allow, for example, a Server to connect to another Server, or a Switch, nor would we want to make a Physical Interface contain a Server. Is something like this in the plans? Of course the use of these constraints would be completely optional. Thanks! -Jason -- 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/d/optout.
[Neo4j] Re: Feature request: 'virtual' relationships in result sets
I'm guessing you just want some indication that there's a path (or no path)
between N1 and N2?
I guess a bit more context would help to determine what you're trying to do
exactly - what's the use case?
On Monday, July 14, 2014 1:01:13 AM UTC-4, Mars Agliullin wrote:
Hello, group
I have a use case for 'virtual' (i.e. created on the fly, not persistent
in DB) relationships. Say, we're looking for pairs of nodes (n1), (n2) in
DB, that are related somehow (e.g. traversable from n1 to n2). We're not
interested in intermediate nodes or relationships between n1 and n2.
Besides n1 and n2 (and their pairing) result set contains other
components; e.g.:
match (n0)-[r]-(n1)-[*1..10]-(n2)
where ...
return n0, r, [n1, n2]
If graph format is used for results (good for its brevity), we either get
the whole subgraph including components of all paths from n1 to n2, which
may be huge and is not needed, or lose pairing between n1 and n2. A better
alternative would be to return n1, n2 and a 'virtual' relationship from n1
to n2:
match (n0)-[r]-(n1)-[*1..10]-(n2)
where ...
return n0, r, n1, n2, relationship(n1, n2, Some label, { name: Some
name })
, where relationship() is a proposed function, returning 'virtual'
relationships.
Any ideas?
--
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/d/optout.
[Neo4j] What are the plans for mixed-type arrays
Hello! I was just wondering what, if any, plans there are in regard to mixed-type arrays for properties. Thanks! -Jason -- 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/d/optout.
Re: [Neo4j] What are the plans for mixed-type arrays
Didn't have any specific plans, but was rather just curious if mixed type arrays were on the road map. Of course, maps would be nice! On Wednesday, July 9, 2014 5:46:51 PM UTC-4, Michael Hunger wrote: There are no plans for that, rather for more complex data types at some point (maps, nested documents) but not in the close future. What do you want to do? Michael On Wed, Jul 9, 2014 at 7:13 PM, Jason Gillman Jr. mackdad...@gmail.com javascript: wrote: Hello! I was just wondering what, if any, plans there are in regard to mixed-type arrays for properties. Thanks! -Jason -- 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/d/optout. -- 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/d/optout.
