RE: manual indexes

[Pieter Martin]

Hi,

I understand that the use of manual indexes are being discouraged.

I have the following scenario...

Vertexes that represent humans and vertexes that represent vehicles.
Both have a name property however I only need to index humans.

Currently I am doing this using manual indexes as I understand that with
a key index all vertexes with a name property will be indexed.

Am I understanding this correctly and if so how to go about doing
indexing only a certain class of vertexes with a keyed index?

Thanks
Pieter

[Stephen Mallette]

At the expense of greater verbosity in property names, I tend to namespace a bit.  Usually it's as simple as just prefixing with the vertex type/class.  So in your case, you might do: humanName/vehicleName.  While you end up typing a bit more, the benefit is not having to maintain indices so that code gets to go away.

Pieter

--
You received this message because you are subscribed to the Google Groups "Gremlin-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gremlin-users+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Pieter Martin]

Ok thanks,

However, I'd prefer it if manual indexes remain an option.

Say for example I only need to index humans living in a particular country?

Thanks
Pieter

To unsubscribe from this group and stop receiving emails from it, send an email to gremlin-user...@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 "Gremlin-users" group.

To unsubscribe from this group and stop receiving emails from it, send an email to gremlin-user...@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.
 
 

Find Top Quality Sites For web developer jobs
http://click.lavabit.com/z4cr718s8cij77k18asjc7dgdkgtho19qubizp841665cgxyqp9b/

[Marko Rodriguez]

Hi,

Say for example I only need to index humans living in a particular country?

A query of that form could be solved by simply getting the country and then enumerating all the people ---

g.V('countryName','USA).in('livesIn')

HTH,

Marko.

http://thinkaurelius.com

[Pieter Martin]

Hi,

Thinking about it a bit more I have the following scenario that I use often.

For one to one and many to many relationship I often need to subset the relationship according to a property of the many. In UML terminology the many property is qualified.

For example a one to many from Parent to Child.
Parents need to find their children by their name.

For every such qualified property (in this case Parent.child) I create a separate index.
I then index the child by key:parentId + 'name', value child's name

I can then use the index for a parent to find its children by name.
I can also use the index to ensure multiplicity, eg. child's name must be unique in the context of its parent.

This has some overlap with the Vertex Queries of blueprints 2.4.0

Previously on sql db this would have been achieved by a creating a composite index on the parent id foreign key column and the name column on the child table.

If custom indexes are to go will the above be achievable with Vertex Queries?

Thanks
Pieter

Find Top Quality Sites For distance learning
http://click.lavabit.com/65dw73o4kd3ar5yyoncye5jigja558yzkko88r67disa4hptg6uy/

[Pieter Martin]

Hi,

    g.V('countryName','USA).in('livesIn')

Thats assuming country was modeled as a class with its own vertex.

It could be legacy system where country is just a java enum, i.e. a string or int property on the vertex. In such a case I would create a composite index on name and country.

The name spacing of properties also worries me. At work we have close to 2000 entities, currently using hibernate, but working on porting it all to the tinkerpop stack. To worry about a name clash at the property level is a pain. We could name properties by their fully qualified name (eg org::this::that::Human::name) but that will make queries much harder to write and a tad silly.

Anyhow just trying to understand how to solve problems that we currently use custom indexes for.

Thanks
Pieter


On 19/05/2013 17:21, Marko Rodriguez wrote:

Your personal email. Anytime, anywhere.
Ridiculously affordable at $19.95. No contracts.
http://www.getpeek.com/lavabit.html

[Zach Kinstner]

To worry about a name clash at the property level is a pain.

Just an idea -- I'm not sure if it's feasible for your particular scenario: consider creating a property-name mapping, which allows your application code to operate with names that are much different than your graph database properties (code example).

This abstraction helps you create unique property names within the database. For example, my "User.Name" property reduces to "U_Na".  As discussed here, this abstraction can be beneficial if you need to re-index existing data -- you can switch to a new database property name without changing your application code -- just update your mappings.  Also, using shorter database property names reduces the size of JSON query results.

[Marko Rodriguez]

Hi,

With GraphQuery, you can do:

Graph.query().has('country','USA').has('name','marko').vertices()

- Blueprints (2.3.0+)

g.V.has('country','USA').has('name','marko')

- Gremlin (2.4.0-SNAPSHOT)

This will compile to a GraphQuery object and its up to the underlying database to resolve it. If composite indices are provided, then that. If not, there is always a default implementation provided by Blueprints --- at worst, linear scan.

HTH,

Marko.

http://markorodriguez.com

[Pieter Martin]

Thanks for that, I agree its a useful abstraction to have.

Do you do some sort of pre-parsing / translation of queries or do users have to know that a property at the db level's name is "U_Na"?

Pieter

[Zach Kinstner]

Do you do some sort of pre-parsing / translation of queries

 

Yes, the property names are translated (via those mappings) when building queries and parsing the results. Context: my project (Fabric) communicates with a graph cluster (via TCP with RexConnect), and gets query results in JSON format. Much of Fabric's domain classes and related query functionality is actually generated code, powered by Fabric's graph schema.

This allows Fabric to do things like User.FillWithData() -- the generator knows both C# and graph property names, so it can build this deserializing function accordingly.

Constructing Gremlin queries is a bit more complicated, because I've added an additional layer of complexity.  My Weaver project lets Fabric build strongly-typed Gremlin queries based on the graph schema. Weaver knows about the property mappings, as well, and will convert C# code like this:

myWeaverObj.BeginPath<User>(x => x.Name, "Zach")

Into (parameterized, if desired) Gremlin:

g.V('U_Na','Zach')

[Pieter Martin]

Hi,

Great, thanks for explaining. Reckon I'll have to do something similar. I am also generating the domain model, (running in embedded mode), from UML class diagrams in my case, so will be able to know how to translate queries at runtime.

Thanks
Pieter

[Zach Kinstner]

Hi Pieter,

In case you are using .NET and interested in Weaver, I just created a README file with more information.

Here's an example of building a query. It finds a Member based on User/App connections, then filters on the Member type:

IWeaverFuncAs<Member> memAlias;

IWeaverQuery q = 
    myWeaverObj.BeginPath<User>(x => x.ArtifactId, 123).BaseNode
    .DefinesMemberList.ToMember
        .As(out memAlias)
    .InAppDefines.FromApp
        .Has(x => x.ArtifactId, WeaverFuncHasOp.EqualTo, 456)
    .Back(memAlias)
    .HasMemberTypeAssign.ToMemberTypeAssign
        .Has(x => x.MemberTypeId, WeaverFuncHasOp.NotEqualTo, (byte)MemberTypeId.None)
        .Has(x => x.MemberTypeId, WeaverFuncHasOp.NotEqualTo, (byte)MemberTypeId.Invite)
        .Has(x => x.MemberTypeId, WeaverFuncHasOp.NotEqualTo, (byte)MemberTypeId.Request)
    .Back(memAlias)
    .End();

SendGremlinRequest(q.Script, q.Params);

[Pieter Martin]

Hi,

Alas I am a java dude.

However I am wondering if you do the translation in the other direction. Allow users to write gremlin queries using the model's name space as opposed to the graph's.

i.e. g.v(1).name -> must somehow be translated into g.v(1).humanName or g.v(1).monkeyName depending on the g.v(1)'s type.

For the gui I am working on, users always runs queries from a context object, the type of which is known. This allows for type aware code insight (in theory) and protect the user from having to worry about name spacing strategies on the database.

I am not (yet) familiar with gremlin but perhaps some translation pipe or something will do the magic?

All that said I dislike hiding stuff from the user as it tends to obfuscation.

Thanks
Pieter

[Zach Kinstner]

I think Fabric does something similar to what you've described, except users send their traversals via URL path (Fabric is a web API). They might request:

/root/Member(1234)/CreatesArtifactList/Limit(0,20)

The URI steps hide edge traversals -- each step traverses from vertex list A, to vertex list B. Each step internally knows how to write its own Gremlin script. "CreatesArtifactList", for example, converts into:

.outE('MemberCreatesArtifact").inV

The graph schema makes it possible to automatically generate all the code for these traversals. Each step's "conversion" process also includes a hook where my non-generated code can modify something, if necessary.  Does that help?

[Pieter Martin]

Yeah, it helps to see what others are doing.

Thanks
Pieter