Yes, that would work. The challenge with this kind of graph is that I've got to go in different directions from the start node to find the result and those paths are difficult to combine and the have optional sub-paths. At the end of the day, I still want person nodes- rows with multiple columns each for a person, with some columns per row possibly null is a bit of a pain to deal with.
Regards
Luanne
Sent from my iPad
On 28-Apr-2012, at 1:47 PM, Andres Taylor <andres.tay...@neotechnology.com> wrote:
> Yes, that would work. The challenge with this kind of graph is that I've got to go in different directions from the start node to find the result and those paths are difficult to combine and the have optional sub-paths. At the end of the day, I still want person nodes- rows with multiple columns each for a person, with some columns per row possibly null is a bit of a pain to deal with.
> Regards
> Luanne
> Sent from my iPad
> On 28-Apr-2012, at 1:47 PM, Andres Taylor <andres.tay...@neotechnology.com> wrote:
>> On Fri, Apr 27, 2012 at 8:41 PM, Luanne Coutinho <luanne.couti...@gmail.com> wrote:
>> Hi,
> Do you run these queries embedded or against the server?
> It should be pretty simple to combine them in the client into a single-column stream? Just a nested iterator.
> Michael
> Am 28.04.2012 um 15:06 schrieb Luanne Misquiita:
>> Yes, that would work. The challenge with this kind of graph is that I've got to go in different directions from the start node to find the result and those paths are difficult to combine and the have optional sub-paths. At the end of the day, I still want person nodes- rows with multiple columns each for a person, with some columns per row possibly null is a bit of a pain to deal with.
>> Regards
>> Luanne
>> Sent from my iPad
>> On 28-Apr-2012, at 1:47 PM, Andres Taylor <andres.tay...@neotechnology.com> wrote:
>>> On Fri, Apr 27, 2012 at 8:41 PM, Luanne Coutinho <luanne.couti...@gmail.com> wrote:
>>> Hi,