Titan 0.3.0

1,825 views
Skip to first unread message

Matthias Broecheler

unread,
Mar 7, 2013, 5:27:57 AM3/7/13
to aureliu...@googlegroups.com
Hey guys,

just wanted to share with you an update on the Titan roadmap. We re-prioritized a bunch of features and decided that it was about time to remove some technical debt in the Titan core module. This turned out into a major rewrite Titan's internals which opened the door to adding some great new features. With that many changes, Titan 0.3.0 will be backwards incompatible, so we decided to do a 0.2.1 release first, which includes a bunch of bugfixes, the multi-module refactoring and other changes that we have added to master over the last two months. Titan 0.2.1-SNAPSHOT has been deployed to sonatype and will be released in two weeks.

Titan 0.3.0-SNAPSHOT currently lives in the "indexing" branch which indicates one of the major new features that will be coming in Titan 0.3.0: full-text indexing, numeric range indexing, and geospatial indexing for both vertices and edges. These advanced indexing capabilities are provided by ElasticSearch (http://www.elasticsearch.org/) and Lucene (http://lucene.apache.org/) which are now integrated into Titan and available as Titan modules. Similarly to storage backends, Titan abstract external indexes which allows it to interface with arbitrary indexing solutions. We chose Lucene for this initial release because its the most popular and most mature indexing system in the open source domain. Like BerkeleyDB, it is designed for single machine use. ElasticSearch is a fairly young but quickly maturing open source project build on top of Lucene that scales to multiple servers and is robust against failure. Hence, it is an ideal partner for Cassandra or Hbase.

To include one of the two external indexes into your project, you simply configure them in your properties file. For instance:

storage.index.search.backend=com.thinkaurelius.titan.diskstorage.es.ElasticSearchIndex
storage.index.search.hosts=[LIST_OF_HOST_IPs]

Here, "search" is the name you give to your index. Since you can register multiple external indices with Titan, each is uniquely identified by its name.

Now, you can tell Titan to index certain keys for you:

graph.makeType().name('time').dataType(Long.class).indexed('search', Edge.class).indexed(Vertex.class).unique(Direction.OUT).makePropertyKey();
graph.makeType().name('location').dataType(Geoshape.class).indexed('search', Edge.class).indexed('search',Vertex.class.unique(Direction.OUT).group(PROPG).makePropertyKey();

So, you use "indexed" to tell Titan that you want a particular key to be indexed and then you specify the name of the index you want to use ("search") and whether you want to index vertices or edges. That's right, Titan supports edge indexing now. If you leave out the name of the index (as we do for the 'time' key and vertices), then it defaults to Titan's "standard" indexing mechanism, namely using the underlying storage backend for indexing. This is what Titan provided all along for equality lookups.
Note, that Titan has its own geo-representation (Geoshape) which makes it easy for you to indexes vertices and edges by their location.

To query, you do:

g.query().has('time',Cmp.GREATER_THAN,System.currentTimeMillis()-1000000).has('location',Geo.WITHIN,Geoshape.circle(33.0,22.0,100)).edges()

which constitutes an "AND" query for all edges that have a timestamp larger than 1000 seconds ago and are within 100 km around that random geo point I inserted there.

I hope that gives you an idea for how this works. As with storage backends, all indexing handling is done by Titan and you can do everything at the level of the graph.

Since a lot of people have asked for this feature, I thought you might want to take a look at Titan 0.3.0-SNAPSHOT and play around with it to give us some feedback on this new feature. Note, that Titan 0.3.0 is not yet stable as we are still tinkering with the interface and sorting out some hyper threading issues.
Other things that are new in 0.3.0:
- use "unique" in type definitions to mark labels and keys as functional (i.e. unique(Direction.OUT)). That allows us to remove that mathematical "functional".
- complete rewrite of the caching engine which is now much better about caching vertex centric query results
- better byte representation and lazy de-serialization for better performance
- better query optimization and query rewriting for both vertex centric queries and global graph queries
- Edge now longer extends Vertex. Access to unidirectional edges through get/setProperty
- Properties on vertices can have properties on them (mind boggling...) which is very useful for version, timestamping, etc

So, lots of new stuff. Please check it out and let us know if you find any issues.

Thanks,
Matthias



--
Matthias Broecheler
http://www.matthiasb.com

Pablo Pareja

unread,
Mar 7, 2013, 6:38:40 AM3/7/13
to aureliu...@googlegroups.com
Great!

Really looking forward to the 0.3.0 version ;)

Pablo

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



--
Pablo Pareja Tobes 

subhankar biswas

unread,
Mar 7, 2013, 7:00:19 AM3/7/13
to aureliu...@googlegroups.com
awesome......when is the projected time to release 0.3....eagerly waiting for it.......

and congrats for the release...or should i say thanks ... :)

Matthias Broecheler

unread,
Mar 7, 2013, 2:20:43 PM3/7/13
to aureliu...@googlegroups.com
Planning to release one week after 0.2.1 to avoid confusion. So, in about 3 weeks.

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

Marko Rodriguez

unread,
Mar 7, 2013, 6:32:09 PM3/7/13
to aureliu...@googlegroups.com
Hi,

TinkerPop 2.3.0 (release in ~1.5 weeks) will have Graph.query() … It will slowly consume KeyIndexableGraph.

Marko.


On Mar 7, 2013, at 3:46 PM, Bryn Cooke <bryn...@gmail.com> wrote:

This looks great. I can't wait to start using it.

Out of interest, do you think that the query API will eventually make it into Blueprints?

Bryn

Eric Scrivner

unread,
Mar 7, 2013, 7:45:51 PM3/7/13
to aureliu...@googlegroups.com
Sounds fantastic. Can't wait to start experimenting with 0.2.1 / 0.3.0.

Jonathan Haddad

unread,
Mar 7, 2013, 7:54:50 PM3/7/13
to aureliu...@googlegroups.com
This sounds pretty amazing.  Since the new version will be incompatible with .2, does that mean you'll be including a migration script, or will it require a dump & reload of the graph?

On Thursday, March 7, 2013 2:27:57 AM UTC-8, Matthias wrote:

defermat

unread,
Mar 7, 2013, 7:07:50 PM3/7/13
to aureliu...@googlegroups.com
Awesome stuff. Looking forward to a lot of the new features. Is the
indexing going to allow for additional indices to be added after the
graph has been created?

Charlie

Matthias Broecheler

unread,
Mar 7, 2013, 8:15:40 PM3/7/13
to aureliu...@googlegroups.com
We are working on making Faunus capable to doing upgrades like that. Titan 0.3 will have a different disk representation of edges so a migration script is not feasible for distributed deployments. The upgrade process will not be available with Titan 0.3 immediately, hence the dual release.

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

Matthias Broecheler

unread,
Mar 7, 2013, 8:20:25 PM3/7/13
to aureliu...@googlegroups.com
So, you can add new index providers but types will continue to be unmodifiable (i.e. cannot change their indexing properties) until a future version. Updating types is a tricky business that will keep us busy for a little while longer....

defermat

unread,
Mar 7, 2013, 8:40:14 PM3/7/13
to aureliu...@googlegroups.com
Got it, sounds good. Thanks.

subhankar biswas

unread,
Mar 8, 2013, 7:14:45 AM3/8/13
to aureliu...@googlegroups.com
could not start titan+cas embbedded while adding ES plugin
my titan config is---

storage.backend=embeddedcassandra
storage.cassandra-config-dir=file:///home/justdial/work/TITAN/titan-indexing/config/cassandra.yaml
storage.keyspace=GraphTitan
storage.connection-pool-size=96
storage.read-consistency-level=QUORUM
storage.write-consistency-level=QUORUM
storage.replication-factor=1
ids.block-size=100000
storage.index.search.backend=com.thinkaurelius.titan.diskstorage.es.ElasticSearchIndex
storage.index.search.hosts=127.0.0.1

and error is 
13/03/08 17:49:05 INFO es.ElasticSearchIndex: Configured remote host: 127.0.0.1 : 9300
13/03/08 17:49:05 ERROR service.CassandraDaemon: Exception in thread Thread[main,5,main]
java.lang.IllegalArgumentException: Could not instantiate implementation: com.thinkaurelius.titan.diskstorage.es.ElasticSearchIndex
at com.thinkaurelius.titan.diskstorage.Backend.getImplementationClass(Backend.java:268)
at com.thinkaurelius.titan.diskstorage.Backend.getIndexes(Backend.java:239)
at com.thinkaurelius.titan.diskstorage.Backend.<init>(Backend.java:98)
at com.thinkaurelius.titan.graphdb.configuration.GraphDatabaseConfiguration.getBackend(GraphDatabaseConfiguration.java:413)
at com.thinkaurelius.titan.graphdb.database.StandardTitanGraph.<init>(StandardTitanGraph.java:62)
at com.thinkaurelius.titan.core.TitanFactory.open(TitanFactory.java:40)
at com.thinkaurelius.titan.tinkerpop.rexster.RexsterTitanServer.start(RexsterTitanServer.java:59)
at com.thinkaurelius.titan.tinkerpop.rexster.RexsterTitanServer.startDaemon(RexsterTitanServer.java:69)
at com.thinkaurelius.titan.tinkerpop.rexster.RexsterTitanServer.main(RexsterTitanServer.java:106)
Caused by: java.lang.reflect.InvocationTargetException
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:57)
at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.lang.reflect.Constructor.newInstance(Constructor.java:525)
at com.thinkaurelius.titan.diskstorage.Backend.getImplementationClass(Backend.java:257)
... 8 more
Caused by: org.elasticsearch.client.transport.NoNodeAvailableException: No node available
at org.elasticsearch.client.transport.TransportClientNodesService.execute(TransportClientNodesService.java:202)
at org.elasticsearch.client.transport.support.InternalTransportClusterAdminClient.execute(InternalTransportClusterAdminClient.java:85)
at org.elasticsearch.client.support.AbstractClusterAdminClient.health(AbstractClusterAdminClient.java:79)
at org.elasticsearch.action.admin.cluster.health.ClusterHealthRequestBuilder.doExecute(ClusterHealthRequestBuilder.java:87)
at org.elasticsearch.action.ActionRequestBuilder.execute(ActionRequestBuilder.java:62)
at org.elasticsearch.action.ActionRequestBuilder.execute(ActionRequestBuilder.java:57)
at com.thinkaurelius.titan.diskstorage.es.ElasticSearchIndex.<init>(ElasticSearchIndex.java:146)
... 13 more
13/03/08 17:49:05 INFO thrift.ThriftServer: Stop listening to thrift clients
13/03/08 17:49:05 INFO gms.Gossiper: Announcing shutdown
13/03/08 17:49:06 INFO net.MessagingService: Waiting for messaging service to quiesce
13/03/08 17:49:06 INFO net.MessagingService: MessagingService shutting down server thread.
 

Matthias Broecheler

unread,
Mar 8, 2013, 1:39:49 PM3/8/13
to aureliu...@googlegroups.com
Hey,

with this configuration, you need to run ElasticSearch before starting titan because you configured it for remote connection but there is no elastic search server running locally.

Change the configuration to:

storage.index.search.backend=com.thinkaurelius.titan.diskstorage.es.ElasticSearchIndex
storage.index.search.local-mode=true
storage.index.search.client-only=false
storage.index.search.directory=/tmp/es

This should run it embedded.
HTH,
Matthias

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

subhankar biswas

unread,
Mar 8, 2013, 2:21:32 PM3/8/13
to aureliu...@googlegroups.com
i thought it would start es as it runs cassandra ....
it is working now
which is advisable local or remote mode....
anyway we r planning to deploy ES for our other search applications in near future then is it better to deploy ES in cluster mode from now.....

and thanks for help.....

Matthias Broecheler

unread,
Mar 8, 2013, 2:45:35 PM3/8/13
to aureliu...@googlegroups.com
ElasticSearch is a pretty new component for us, so my advice on that is not yet solid.
For now, I would advise you to run elastic search in remote mode, in particular if you are running with cassandra embedded. There might be resource interference between cassandra and ES.

subhankar biswas

unread,
Mar 8, 2013, 2:48:20 PM3/8/13
to aureliu...@googlegroups.com
thanks.....

Zack Maril

unread,
Mar 9, 2013, 4:37:29 AM3/9/13
to aureliu...@googlegroups.com
Woah. Did you guys get rid of TitanInMemoryBlueprintsGraph? Trying to update hermes and I got blindsided by all the changes to the internals. Could you put up the javadoc for the 0.3.0-SNAPSHOT someplace? 
-Zack

Zack Maril

unread,
Mar 9, 2013, 9:10:54 AM3/9/13
to aureliu...@googlegroups.com
When you say 0.2.1-SNAPSHOT has been deployed but not released, do you mean that the poms are there and not the jars? Because the jars aren't there currently and I wanted to check to see if that's right (0.3.0-SNAPSHOTS jars are there already).
-Zack

Matthias Broecheler

unread,
Mar 9, 2013, 6:59:05 PM3/9/13
to aureliu...@googlegroups.com
Hey Zack,

what I meant to say is that we have deployed both 0.2.1 and 0.3.0 to sonatype so you guys can play with it but its not yet officially released (i.e. still snapshot) as things are still changing.

Yes, a lot of things have changed in 0.3.0 and one of the things that I dropped was InMemoryGraph. I plan on adding a storage backend which is just a sorted hashmap which would give you the same behavior as an InMemoryGraph (but with transactions) and is super trivial to implement (just an implementation of KeyValueStore that uses a ConcurrentSkipListMap), however, I haven't gotten around to that. InMemoryGraph was this special class floating around which made the code unpretty.

Cheers
Mathtias

Jonathan Haddad

unread,
Mar 9, 2013, 9:50:58 PM3/9/13
to aureliu...@googlegroups.com
Gotcha.  We only deployed our first Titan install about a month ago, and are only working with about 1/2 a gig of data - it should still be possible for us to dump our graph as a graphson file, then reload into titan 0.3, right?

Jon

Matthias Broecheler

unread,
Mar 9, 2013, 9:58:24 PM3/9/13
to aureliu...@googlegroups.com
Yes, absolutely.

Marko Rodriguez

unread,
Mar 9, 2013, 10:20:24 PM3/9/13
to aureliu...@googlegroups.com

Hi,

Few things on this.

  1. Make sure you don't have non-primitive property values as Faunus doesn't support them yet. If you do, you can always transfer them over afterwards using this technique: https://github.com/thinkaurelius/faunus/wiki/Distributed-Graph-Computing-with-Gremlin
  2. Make use of a SequenceFile instead of GraphSON for speed. Though, with GraphSON you have an easily parseable backup to use with other tools if need be. Also, with GraphSON, ints are longs.
  3. Make sure to fully set up your indices in Titan 0.3.0 prior to bulk load and don't rely on schema inferencing. Faunus schema inferencing is not type-smart.
  4. Always check the statistics of the graph afterwards to make sure everything came across. Counters to watch for on the final BlueprintsOutputMapReduce is NULL_VERTICES and NULL_VERTEX_EDGES.

Have been dealing with this lately...

Good luck,
Marko.

http://markorodriguez.com

Zack Maril

unread,
Mar 10, 2013, 5:02:05 AM3/10/13
to aureliu...@googlegroups.com

Matthias Broecheler

unread,
Mar 11, 2013, 12:14:43 AM3/11/13
to aureliu...@googlegroups.com
My intuition would be that those should both have jars. The process for deploying is exactly the same...
Not sure why there is a difference.

Zack Maril

unread,
Mar 11, 2013, 11:39:08 AM3/11/13
to aureliu...@googlegroups.com
Yeah, I'm having trouble getting the 0.2.1-SNAPSHOT to download at all. Maven can find the pom's no problem but it gets stuck trying to find the jar's on sonatype. I'm using this as the artifact identifier: 
[com.thinkaurelius.titan/titan "0.2.1-SNAPSHOT"] (Clojure way of doing maven) 

I don't think the jar's have been deployed anywhere for 0.2.1-SNAPSHOT. 
-Zack 

Matthias Broecheler

unread,
Mar 14, 2013, 12:39:42 AM3/14/13
to aureliu...@googlegroups.com
Mmh, I will try to redeploy this.

Zack Maril

unread,
Mar 18, 2013, 8:32:14 AM3/18/13
to aureliu...@googlegroups.com
Was rereading this message:
- Properties on vertices can have properties on them (mind boggling...) which is very useful for version, timestamping, etc

I've been considering how to make Titan immutable at some level. While it is currently possible within an application with very careful management of how you interact with Titan, I have a feeling the above would allow someone to really easily write some general code that would allow anyone to interact with an effectively immutable graph database (which seems counterintuitive at first, but ends up being quick useful). It would be very similar to datomic:

Neat!
-Zack

Matthias Broecheler

unread,
Mar 18, 2013, 11:59:26 AM3/18/13
to aureliu...@googlegroups.com
Hey Zack,

I think of Titan as an immutable database but in a slightly different sense. Edges and properties in Titan cannot be modified once they are created but can be deleted. Hence, every graph mutation is translated into a deletion and addition operation.

Imho, being able to delete is an important aspect of any serious database system. There are many applications where being able to delete is an important requirement. Furthermore, "forgetting" is an important feature of our brain (and not a limitation as some might think) and hence I believe that any semi-intelligent system must have the ability to "forget", i.e. delete things.
That's why I think Titan is immutable.

Cheers,
Matthias

Sergey L

unread,
Mar 18, 2013, 2:52:05 PM3/18/13
to aureliu...@googlegroups.com
Why yor choose ES instead Solr - Solr more stable and sync release with Lucene?

Matthias Broecheler

unread,
Mar 18, 2013, 3:23:18 PM3/18/13
to aureliu...@googlegroups.com
Hey Sergey,

check out:

That said, note that it is fairly simple to write a Solr adapter for Titan - requires only one class implementation.

Best,
Matthias

On Mon, Mar 18, 2013 at 11:52 AM, Sergey L <fknis...@gmail.com> wrote:
Why yor choose ES instead Solr - Solr more stable and sync release with Lucene?

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

Sergey L

unread,
Mar 19, 2013, 5:13:26 PM3/19/13
to aureliu...@googlegroups.com
Ok, thanks.

AN

unread,
Mar 25, 2013, 11:20:06 AM3/25/13
to aureliu...@googlegroups.com
I am very interested in integrating ElasticSearch's faceted search and had found a previous thread on this list that deferred it to a future release of Titan that would integrate ES.

It sounds like ES is very close and just wanted to confirm that the current snapshot of Titan has some minimal ES search that I could build upon.  

You mention, "We chose Lucene for this initial release because its the most popular and most mature indexing system in the open source domain," which sounds to me that only Lucene is currently supported?

Also, I do not have any direct experience with ES's faceted search (this will be my first project with it) so please let me know if there might be some inherit issue in pursuing this path when integrating with Titan.

Thanks,
Andrew


On Thursday, March 7, 2013 2:27:57 AM UTC-8, Matthias wrote:
Hey guys,

just wanted to share with you an update on the Titan roadmap. We re-prioritized a bunch of features and decided that it was about time to remove some technical debt in the Titan core module. This turned out into a major rewrite Titan's internals which opened the door to adding some great new features. With that many changes, Titan 0.3.0 will be backwards incompatible, so we decided to do a 0.2.1 release first, which includes a bunch of bugfixes, the multi-module refactoring and other changes that we have added to master over the last two months. Titan 0.2.1-SNAPSHOT has been deployed to sonatype and will be released in two weeks.

Titan 0.3.0-SNAPSHOT currently lives in the "indexing" branch which indicates one of the major new features that will be coming in Titan 0.3.0: full-text indexing, numeric range indexing, and geospatial indexing for both vertices and edges. These advanced indexing capabilities are provided by ElasticSearch (http://www.elasticsearch.org/) and Lucene (http://lucene.apache.org/) which are now integrated into Titan and available as Titan modules. Similarly to storage backends, Titan abstract external indexes which allows it to interface with arbitrary indexing solutions. We chose Lucene for this initial release because its the most popular and most mature indexing system in the open source domain. Like BerkeleyDB, it is designed for single machine use. ElasticSearch is a fairly young but quickly maturing open source project build on top of Lucene that scales to multiple servers and is robust against failure. Hence, it is an ideal partner for Cassandra or Hbase.

To include one of the two external indexes into your project, you simply configure them in your properties file. For instance:

storage.index.search.backend=com.thinkaurelius.titan.diskstorage.es.ElasticSearchIndex
storage.index.search.hosts=[LIST_OF_HOST_IPs]

Here, "search" is the name you give to your index. Since you can register multiple external indices with Titan, each is uniquely identified by its name.

Now, you can tell Titan to index certain keys for you:

graph.makeType().name('time').dataType(Long.class).indexed('search', Edge.class).indexed(Vertex.class).unique(Direction.OUT).makePropertyKey();
graph.makeType().name('location').dataType(Geoshape.class).indexed('search', Edge.class).indexed('search',Vertex.class.unique(Direction.OUT).group(PROPG).makePropertyKey();

So, you use "indexed" to tell Titan that you want a particular key to be indexed and then you specify the name of the index you want to use ("search") and whether you want to index vertices or edges. That's right, Titan supports edge indexing now. If you leave out the name of the index (as we do for the 'time' key and vertices), then it defaults to Titan's "standard" indexing mechanism, namely using the underlying storage backend for indexing. This is what Titan provided all along for equality lookups.
Note, that Titan has its own geo-representation (Geoshape) which makes it easy for you to indexes vertices and edges by their location.

To query, you do:

g.query().has('time',Cmp.GREATER_THAN,System.currentTimeMillis()-1000000).has('location',Geo.WITHIN,Geoshape.circle(33.0,22.0,100)).edges()

which constitutes an "AND" query for all edges that have a timestamp larger than 1000 seconds ago and are within 100 km around that random geo point I inserted there.

I hope that gives you an idea for how this works. As with storage backends, all indexing handling is done by Titan and you can do everything at the level of the graph.

Since a lot of people have asked for this feature, I thought you might want to take a look at Titan 0.3.0-SNAPSHOT and play around with it to give us some feedback on this new feature. Note, that Titan 0.3.0 is not yet stable as we are still tinkering with the interface and sorting out some hyper threading issues.
Other things that are new in 0.3.0:
- use "unique" in type definitions to mark labels and keys as functional (i.e. unique(Direction.OUT)). That allows us to remove that mathematical "functional".
- complete rewrite of the caching engine which is now much better about caching vertex centric query results
- better byte representation and lazy de-serialization for better performance
- better query optimization and query rewriting for both vertex centric queries and global graph queries
- Edge now longer extends Vertex. Access to unidirectional edges through get/setProperty
- Properties on vertices can have properties on them (mind boggling...) which is very useful for version, timestamping, etc

So, lots of new stuff. Please check it out and let us know if you find any issues.

Thanks,
Matthias



Matthias Broecheler

unread,
Mar 25, 2013, 1:18:11 PM3/25/13
to aureliu...@googlegroups.com
Hey Andrew,

ElasticSearch and Lucene integration will come with Titan 0.3.0 which has been released as SNAPSHOT and is currently in the "indexing" branch of the repo. Both index providers will be supported.
For now, we will only support boolean search through Titan - that is, faceted search is not yet supported.

Best,
Matthias

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

robo...@gmail.com

unread,
Apr 9, 2013, 3:54:54 PM4/9/13
to aureliu...@googlegroups.com

robo...@gmail.com

unread,
Apr 9, 2013, 3:58:09 PM4/9/13
to aureliu...@googlegroups.com
Hi Matthias,

If possible, could you please share more details about the class implementation for this solr adapter for titan? Thanks!

Matthias Broecheler

unread,
Apr 10, 2013, 11:21:23 AM4/10/13
to aureliu...@googlegroups.com
Hey,

we don't have a solr adapter for Titan yet. Only ElasticSearch and Lucene are supported at this point.

Best,
Matthias
Reply all
Reply to author
Forward
0 new messages