| 31d1320 | Dan LaRocque | 13 February 2015, 21:25:30 UTC | Add 0.5.4 to compat manifest | 13 February 2015, 21:25:30 UTC |
| fb74209 | Dan LaRocque | 13 February 2015, 21:25:29 UTC | [maven-release-plugin] prepare for next development iteration | 13 February 2015, 21:25:29 UTC |
| 141cd4c | Dan LaRocque | 13 February 2015, 21:25:29 UTC | [maven-release-plugin] prepare release 0.5.4 | 13 February 2015, 21:25:29 UTC |
| 6c5d25d | Dan LaRocque | 13 February 2015, 21:24:24 UTC | Updating titan.compatible.versions prop | 13 February 2015, 21:24:24 UTC |
| d78a080 | Dan LaRocque | 13 February 2015, 20:35:46 UTC | Fix HBase + TTL + Metrics 278d8b988058183ed032b03959771864f6b37a0c introduced an exception during graph startup when configured to use HBase with Metrics. This causes setup errors in HBaseOperationCountingTest, but it's not just an issue of updating some outdated expectation numbers as in ee8f75a604071db919f0a18a11a1bc72cc1c883f. This is actually a problem with Titan proper. The commit that introduced this regression wraps the backend with MetricsInstrumentedStoreManager early in startup, before wrapping with TTLKCVSManager. TTLKCVSManager expects `instanceof CustomizeKCVSManager` on its encapsulated backend to be true unless it implements cell-level TTL; this is true of HBaseSM, but not of MetricsInstrumentedSM. Doing instanceof <some manager-extension interface> in wrappers is generally problematic since we have so many manager/store wrapper classes. The typecasts prevent the compiler from helping us catch this stuff. However, this is (hopefully) the last commit before the next bugfix release, so I don't want to go overboard with hurried refactoring and break something else. I made TTLKCVSManager implement CustomizeStoreKCVSManager and check that its wrapped backend is instanceof same when the openDatabase(name, ttl) method is invoked. | 13 February 2015, 20:51:20 UTC |
| 5f2a016 | Dan LaRocque | 13 February 2015, 10:31:20 UTC | Set tentative release date for 0.5.4 | 13 February 2015, 10:31:20 UTC |
| ee8f75a | Dan LaRocque | 13 February 2015, 09:34:03 UTC | Update TitanOperationCountingTest magic numbers This commit fixes expected method invocation counts for getSlice and acquireLock in TitanOperationCountingTest assertions broken by 278d8b988058183ed032b03959771864f6b37a0c. That commit moved the code that increments counters for KCVS.* or StoreManager.mutateMany method calls such that BDB still passes, but stores that use the consistent key locker (Cassandra + HBase) fail. The counting now seems to happen after ExpectedValueCheckingStore/Manager method is invoked, but before the HBaseKCVS/Manager or Cassandra*KCVS/Manager method is invoked. Hence acquireLock is apparently never invoked, and getSlice is subject to additional invocations as the ExpectedValue classes verify that the actual stored values match those required by lock requests. | 13 February 2015, 09:34:03 UTC |
| 4976d93 | Dan LaRocque | 11 February 2015, 21:02:42 UTC | Increase a TTL-sensitive test timeout The assertion following the sleep tweak in this commit would periodically fail as though TTL expiration had not yet been processed. Doubled the sleep. | 11 February 2015, 21:23:42 UTC |
| 194bd33 | Dan LaRocque | 11 February 2015, 20:54:06 UTC | Avoid stopwords in testContainsWithMultipleValues 2a99d97913d8c05c7a53ceca77af944452fcde4c brought a new test method, testContainsWithMultipleValues, for #909. This passed on solr, but I failed to notice that it failed on lucene. The test ran a CONTAINS query on "was here". On Solr, the query matches the expected property, but on Lucene, it doesn't match even though the data are the same. If I'm reading the Solr and Lucene docs and test configs correctly, then I think "was" is configured as a stopword for both of them. I think I've also ruled out dynamic field mapping as a potential culprit -- the field in the test is getting named 1|1_t, and there's a dynamic mapping for *_t in the schema file. The FieldType also looks right; it's got to stopwords.txt. I also see stopwords.txt pushed into the Solr server config when I turn org.apache.solr logging up to DEBUG. Really not sure where the discrepancy is. Reconciling this difference was consuming a bunch of time for unclear gains, so I eventually tapped out and just changed the query string from "was here" to "here hercules". The code exercised is the same as when searching for "was here", but this avoids common stopwords. For #965 | 11 February 2015, 21:23:42 UTC |
| 71bd1d7 | Dan LaRocque | 11 February 2015, 10:15:08 UTC | Use Groovysh `set` builtin for result peek sizes When a gremlin.sh command evaluates to an iterable, the number of initial elements in the iterable printed to the console is now controlled by a pair of Groovysh settings: * `set tp-olap-result-peek <int>` (default 50) * `set tp-oltp-result-peek <int>` (default 500) The OLAP setting controls the number of initial lines read out of result files produced by executing a HadoopPipeline (i.e. a titan-hadoop/Faunus job). The OLTP setting controls the number of initial elements read out of any other iterable result. Negative ints are treated as if Integer.MAX_VALUE were specified. Zero has slightly special interpretation; it completely disables iterator peeking. Zero means that the shell will not even call hasNext to decide whether to print "...". Positive ints are used exactly as specified. Settings are persistent across gremlin.sh sessions. They're stored in the Java user Preferences system under the node "/org/codehaus/groovy/tools/shell". On *NIX systems, this is usually in ~/.java/.userPrefs/org/codehaus/groovy/tools/shell/prefs.xml. You may notice that the implementation in this commit does not actually call Preferences.flush anywhere to guarantee persistence. It relies instead on this guarantee from the Preferences javadoc: "Normal termination of the Java Virtual Machine will not result in the loss of pending updates -- an explicit flush invocation is not required upon termination to ensure that pending updates are made persistent." For #924 | 11 February 2015, 11:18:03 UTC |
| dcf2924 | Dan LaRocque | 11 February 2015, 08:49:57 UTC | Revert "Optionify the # of result elems shown in the shell" This reverts commit 5298f5d923fd2fbf276b40d7c20d4d56fd2f0621. Reverting per recent discussion in #924. | 11 February 2015, 08:49:57 UTC |
| 86a142e | Dan LaRocque | 10 February 2015, 05:53:30 UTC | Updating READMEish files for 0.5.4 | 10 February 2015, 19:39:54 UTC |
| 5298f5d | Dan LaRocque | 10 February 2015, 05:38:41 UTC | Optionify the # of result elems shown in the shell Since 645b406468f06c043b810375d6203618b505b241 made the Console.LINES limit apply non-hadoop result collections for what appears to be the first time, it's possible that the 15 element limit may surprise some people and prove annoyingly low. This commit retains the 15 element limit default, but it makes the actual number of elements configurable on the gremlin.sh command line via the -w <number> option, e.g. bin/gremlin.sh -w 50 will print up to fifty elements from a result collection before truncating any remaining elements (and if at least one element remains after those initial fifty, printing a set of ellipses). It may be annoying, but at least it's no longer hardcoded. I don't think this breaks compatibility with existing scripts, unless there's someone out there naming their Groovy script files "-w". We don't have a "--" option to disambiguate. | 10 February 2015, 05:43:17 UTC |
| 3736b37 | Dan LaRocque | 10 February 2015, 01:59:26 UTC | Keep vertices together with Cassandra widerows This commit adds a new TitanCassandraWideRecordReader class that gets instantiated when titan-hadoop's configuration includes cassandra.input.widerows=true. This RR attempts to make as many calls to the underlying widerows iterator as necessary to collect all (column,value) entries before considering a FaunusVertex complete and passing it up to the MapReduce task. For #963 | 10 February 2015, 03:05:43 UTC |
| 3c776d4 | Dan LaRocque | 10 February 2015, 01:50:02 UTC | Adding test of titan-hadoop w/ Cassandra widerows This commit adds a test method to TitanCassandraOutputFormatTest that counts vertices with cassandra.input.widerows=true in the titan-hadoop configuration. The test fails as of this commit due to a preexisting bug (fix incoming). For #963 | 10 February 2015, 03:05:43 UTC |
| 4f7647e | Dan LaRocque | 09 February 2015, 17:19:10 UTC | Fix maven assembly->gpg plugin ordering in release For #940 | 10 February 2015, 03:05:42 UTC |
| 645b406 | Dan LaRocque | 09 February 2015, 17:10:53 UTC | Fix gremlin.sh result set ellipses Prior to this commit: * Ellipses were printed whenever a result set iterator printed exactly 15 elements. * Iterators over result files generated by titan-hadoop jobs were hard limited to 15 elements, but non-Hadoop result iterators had no limit, resulting in odd ellipses behavior and no effective limit for non-Hadoop results After this commit: * All result set iterators are subject to the 15 line limit * Iterators over result files generated by titan-hadoop jobs have their internal hard limit set to 16, so that exactly-15 and 15+ are distinguishable for ellipses For #924 | 10 February 2015, 03:05:42 UTC |
| 79a942a | Dan LaRocque | 09 February 2015, 16:07:58 UTC | Stop returning unidir edges as properties titan-hadoop iterates over unidirected edges as if they were properties; this produces an exception as reported in #941. This commit makes FaunusElement.getPropertyKeysDirect stop returning unidirected edges. This avoids the exception in #941. However, dumping edges from Cassandra to GraphSON omits unidirected edges. titan-hadoop could probably use more tweaking to resolve the tension between unidirected edges being represented as relations with a type that extends edge but which use the setProperty interface. The existing TitanOutputFormatTest.testUnidirectionEdges still passes, but given my track record of unintended collateral breakage caused by faunus schema changes during titan05 development, I'm hesitant to declare victory. There may be unintended consequences that I'm missing. | 10 February 2015, 03:03:31 UTC |
| 879c9a1 | Matthias Broecheler | 24 January 2015, 02:13:09 UTC | Updated repetition counter to ensure success | 24 January 2015, 02:13:09 UTC |
| 84138c6 | Matthias Broecheler | 24 January 2015, 01:27:53 UTC | Fixes #939 and bug in previous fix to how we skip constraint verification. | 24 January 2015, 01:27:53 UTC |
| 418944c | Matthias Broecheler | 24 January 2015, 01:12:25 UTC | Merge branch 'titan05' of https://github.com/thinkaurelius/titan into titan05 | 24 January 2015, 01:12:25 UTC |
| 4962db3 | Matthias Broecheler | 24 January 2015, 01:12:06 UTC | Fixes #931 | 24 January 2015, 01:12:06 UTC |
| 41fa561 | Matthias Broecheler | 23 January 2015, 02:02:42 UTC | Added test case for #931 | 23 January 2015, 02:02:42 UTC |
| 278d8b9 | Matthias Broecheler | 23 January 2015, 01:54:37 UTC | Added metrics instrumentation around manager to account for mutateMany calls. Refactored metrics initialization. | 23 January 2015, 01:54:37 UTC |
| 7156dcb | Matthias Broecheler | 23 January 2015, 00:07:53 UTC | Fixes #937 with extra test coverage. | 23 January 2015, 00:07:53 UTC |
| 69b0788 | Dan LaRocque | 15 January 2015, 15:44:07 UTC | Merge branch 'issue_909' into titan05 | 15 January 2015, 15:44:07 UTC |
| 2a99d97 | Pavel Yaskevich | 13 January 2015, 06:12:27 UTC | (Solr) only add + when AND query has more than one condition | 13 January 2015, 06:12:27 UTC |
| 9d650c3 | Dan LaRocque | 09 January 2015, 02:54:44 UTC | Add 0.5.3 to compat manifest | 10 January 2015, 00:21:14 UTC |
| e099458 | Dan LaRocque | 09 January 2015, 02:54:44 UTC | [maven-release-plugin] prepare for next development iteration | 10 January 2015, 00:21:14 UTC |
| 4fad7ce | Dan LaRocque | 09 January 2015, 02:54:43 UTC | [maven-release-plugin] prepare release 0.5.3 | 10 January 2015, 00:21:14 UTC |
| e3f9ce7 | Dan LaRocque | 09 January 2015, 02:53:37 UTC | Updating titan.compatible.versions prop | 10 January 2015, 00:21:14 UTC |
| 6cc7081 | Dan LaRocque | 09 January 2015, 02:52:17 UTC | Updating READMEish files for 0.5.3 | 10 January 2015, 00:21:09 UTC |
| 190d42c | Dan LaRocque | 08 January 2015, 23:07:35 UTC | Changing query fit expectations in tests e538117710d373b4b8690f4c0a32f40206f41890 changed some queries that used to be fitted into unfitted queries. This caused failures in test expectations around fitted-ness. This commit changes several fitted=true expectations to fitted=false in an attempt to match the new implementation behavior. | 08 January 2015, 23:09:15 UTC |
| e538117 | Matthias Broecheler | 08 January 2015, 20:29:09 UTC | Fixes #890 | 08 January 2015, 20:29:09 UTC |
| af0dd8a | Matthias Broecheler | 08 January 2015, 19:48:20 UTC | Fixes #853 | 08 January 2015, 19:48:20 UTC |
| f4291c7 | Matthias Broecheler | 08 January 2015, 19:28:20 UTC | Merge branch 'titan05' of https://github.com/thinkaurelius/titan into titan05 | 08 January 2015, 19:28:20 UTC |
| 4a63653 | Matthias Broecheler | 08 January 2015, 19:25:16 UTC | Fixes #868 | 08 January 2015, 19:25:16 UTC |
| 4ffb0e9 | Matthias Broecheler | 08 January 2015, 18:45:56 UTC | Make index.hostname Maskable so that the hostname can be updated when the external index cluster changes. Fixes #880. | 08 January 2015, 18:45:56 UTC |
| af784bd | Dan LaRocque | 07 January 2015, 13:21:18 UTC | Only apply cache.tx-cache-size min on r/w tx This iterates on a3ea0e5c3cc566984f652619f71b0e058d716909. Read-only transactions can go under the minimum tx-cache-size setting now. Only write-capable transactions are still subject to the minimum. | 07 January 2015, 13:22:45 UTC |
| a3ea0e5 | Dan LaRocque | 07 January 2015, 10:12:30 UTC | Put a min of 100 on cache.tx-cache-size This is a workaround for #893 that's likely to avoid race conditions related to small tx-cache-size values in practice, though it does not technically eliminate the underlying problem. Prior to this commit, I investigated an alternative approach involving WeakReference and a consuming ReferenceQueue drained from the same thread that touches GuavaVertexCache, and that passed Titan's tests appeared to log all the right things via slf4j, but it's still too scary right to introduce so close to a release milestone. The assumption required to make that WeakReference approach work is that dirty vertices are at all times reachable via at least one strong reference *outside* GVC (on any GC root), but it's not completely trivial to prove this for all of Titan's internals. It's also impossible to write a watertight test for the WeakReference approach since its behavior is inextricably linked with GC. | 07 January 2015, 10:13:57 UTC |
| 612ea2d | Dan LaRocque | 07 January 2015, 09:24:12 UTC | Add "args" binding back into ScriptExecutor The Titan ScriptExecutor used to set an "args" variable in the Groovy Binding that pointed to the command-line argument list. The Faunus ScriptExecutor didn't do this. I'm modifying the Faunus ScriptExecutor to set "args" (in addition to the "a1", "a2", ... that it already sets) for backwards-compatibility. This could break existing scripts that explicitly rely on "args" being absent from the variable binding when the script starts, but that seems like an extremely narrow class of scripts. Scripts that first assign to "args" and then do stuff with it should be unaffected. | 07 January 2015, 09:27:15 UTC |
| 4f9ceb0 | Dan LaRocque | 07 January 2015, 09:15:20 UTC | Move argument shift in gremlin.sh This bit of logic has been touched in 018827a538979a93c0b1cd9b4de240e72a235f72 and again in 1b23ce606090eb7e9407e63e26bf8e4e2418ac42, with unintentional regressions in both cases. These options are calling out for automated regression tests. For #903 | 07 January 2015, 09:15:56 UTC |
| 7578354 | Dan LaRocque | 07 January 2015, 07:43:11 UTC | Fix whitespace in graph.set-vertex-id description | 07 January 2015, 07:43:11 UTC |
| da15f29 | Dan LaRocque | 07 January 2015, 07:41:15 UTC | Update links to manual in javadoc comments For #905. This updates the specific outdated URL pointed out by @jaceklaskowski. It also updates several other old wiki URLs turned up by a recursive grep for 'github.*titan/wiki'. | 07 January 2015, 07:41:15 UTC |
| 71325b7 | Stephen Mallette | 05 January 2015, 20:42:32 UTC | Add a note to the docs around Rexster configuration for cassandra to address #908 | 05 January 2015, 20:42:32 UTC |
| 4e38eca | Dan LaRocque | 27 December 2014, 18:43:38 UTC | Removing outdated query precondition This precondition check no longer applies with Contain.IN support, and the underlying invariant it expresses isn't valid anymore. Removing it following discussion with Matthias. For #882 | 27 December 2014, 18:43:38 UTC |
| 5c81611 | Dan LaRocque | 23 December 2014, 16:35:43 UTC | Add failing test with vlabel and Contain.IN conds This is based on #882 | 23 December 2014, 16:36:36 UTC |
| 29491f3 | Dan LaRocque | 22 December 2014, 19:10:45 UTC | Add basic test of ES index creation options This commit adds a test of the new functionality introduced by 6569f8b060a86a6291326e76f5dbe612732b2f7f. For #840 | 22 December 2014, 19:10:45 UTC |
| b08be31 | Dan LaRocque | 19 December 2014, 23:01:04 UTC | Tweak TitanOperationCountingTest expectations This test was broken by de177b9e59b02cd865fb9e49aa4d1a120353ced8 and 03a4c5fb8919d2ff5c0a00c705f0a43818751a95. Updating it to reflect the changes to the way Titan reads schema elements following those changes. | 19 December 2014, 23:03:47 UTC |
| a83e463 | Dan LaRocque | 19 December 2014, 21:18:18 UTC | Add helper method for exception/null-safe rollback This commit introduces a TXUtils.rollbackQuietly which is roughly similar to IOUtils.closeQuietly. This might become obsolete in Titan 0.9 where we can assume try-with-resources and txs are AutoCloseable. First used as part of #881's implementation, but not specifically related to that issue | 19 December 2014, 23:03:47 UTC |
| 9977456 | Dan LaRocque | 19 December 2014, 21:15:40 UTC | Removing tx from SchemaCache method params Now that the SchemaCache.StoreRetrieval implementation constructs a new, cache-disabled transaction for each schema read method invocation, it no longer uses the tx param to its various methods. This lets us remove the tx param from both SchemaCache.StoreRetrieval's methods and SchemaCache's methods. For #881 | 19 December 2014, 23:03:47 UTC |
| e00073c | Dan LaRocque | 19 December 2014, 20:36:09 UTC | Disable cache on correct tx for schema reads de177b9e59b02cd865fb9e49aa4d1a120353ced8 modified StandardTitanGraph.typeCacheRetrieval's retrieveSchemaByName and retrieveSchemaRelations methods to each instantiate a new StandardTitanTx using a key-consistent backend config (i.e. Cassandra QUORUM) inside each retrieve method to perform schema reads. Those methods also disabled cache on a transaction just before the schema reads. However, they disabled cache on the wrong tx -- when I introduced a a new key-consistent tx to these methods for schema reads, I failed to move the disableCache invocation from the old tx to the new key-consistent one. Now cache is disabled on the actual StandardTitanTx used for the schema schema vertex/relation read For #881 | 19 December 2014, 23:03:15 UTC |
| bc88a45 | Dan LaRocque | 18 December 2014, 22:14:32 UTC | Use consistent tx for schema retrieval Experimenting with opening a new transaction with a reference held on the stack solely for the purpose of reading schema vertices and schema relations. For #881 | 19 December 2014, 23:02:25 UTC |
| 24f93bb | Dan LaRocque | 18 December 2014, 14:57:22 UTC | Throw new ExpiredLockException when applicable This commit modifies ConsistentKeyLocker and its superclass to implement the new behavior expected in 6ea5ebf8d0b13c025d08a4734037fb725d0e089c. Previously, a lock that expired while a transaction was holding it would throw a cryptic TemporaryLockingException with the message "No lock columns found for KeyColumn [k=foo, c=bar]". This is not a helpful exception in most cases; the log for ConsistentKeyLocker emits a WARN about the expired lock shortly before this is thrown, but it would be better to have a specific exception type and message to make it clearer about what's happening in this case. Now we have ExpiredLockException. This is a a subclass of TemporaryLockingException. The message string used with it is something like "Expired lock on KeyColumn [k=foo, c=bar]: raw lock timestamp 1418915175000000 MICROSECONDS is older than Duration[300000 ms]". | 18 December 2014, 15:08:16 UTC |
| 6ea5ebf | Dan LaRocque | 18 December 2014, 14:50:15 UTC | Tweak ConsistentKeyLockerTest's expired lock tests This introduces a pair of tests around expired lock behavior: * Check that our own expired locks throw a new ExpiredLockException class when checked * Check that expired locks left behind by other instances, or by the current instance but with a different-than-expected write time, do not necessarily throw an exception in check (unless they prevent the transaction from verifying one or more of its own locks) Previously, only the latter case was implemented and tested. The former case is essentially a special case for #892, wherein we want to provide a more meaningful exception type and message in the event that a transaction's locks expire while held. | 18 December 2014, 14:57:11 UTC |
| bb6a358 | Dan LaRocque | 18 December 2014, 13:54:59 UTC | Minor javadoc improvement on lock status class | 18 December 2014, 13:54:59 UTC |
| 902e80b | Dan LaRocque | 18 December 2014, 13:09:24 UTC | Modify LuceneIndex to support REGEX on STRINGs Lucene (at least at our present version) does not seem to provide a Filter implementation that does regex matching. It does provide a Query implementation for regex matching. LuceneIndex was only built to generate Filters; it always used MatchAllDocsQuery. This change modifies LuceneIndex to allow the convertQuery method to build both a Filter and an accompanying Query. The Lucene REGEX tests introduced in 8f712e70d767313fa4ad401bd295e9bff9fd97bf pass at the moment. For #879 | 18 December 2014, 13:49:31 UTC |
| c298297 | Dan LaRocque | 18 December 2014, 11:22:37 UTC | Enable REGEX tests on Lucene Added a test of Text.REGEX that explicitly specifies Mapping.STRING so that it will activate on Lucene. This commit also makes LuceneIndex report that it supports REGEX, though the implementation just throws an exception right now. The tests are failing. Implementation is up next. For #879 | 18 December 2014, 13:49:31 UTC |
| e306728 | Dan LaRocque | 18 December 2014, 10:55:09 UTC | Deduplicate common ES & Lucene support tests LuceneIndexTest and ElasticSearchIndexTest both implement a testSupport() method that runs assertions on index.supports(...) with a variety of datatypes, mappings, and predicates. Most (but not all) of these testSupport() method bodies were identical between the two test classes. The common segment has been extracted to the shared parent class IndexProviderTest as a new method named testCommonSupport(). This change is intended to simplify upcoming REGEX-related test changes in LuceneIndexTest for #879 | 18 December 2014, 13:49:04 UTC |
| 9d38c24 | Dan LaRocque | 18 December 2014, 08:49:59 UTC | Make Multiplicity/Cardinality explicit in examples For #869 | 18 December 2014, 08:49:59 UTC |
| 50c0998 | Dan LaRocque | 17 December 2014, 17:37:20 UTC | Make Cmp.EQUAL array-aware Array values are now compared with Apache Commons ArrayUtils.isEquals, which is essentially Arrays.equals, but safe for multidimensional arrays. | 17 December 2014, 17:37:20 UTC |
| 2bf1ca3 | Dan LaRocque | 17 December 2014, 17:36:49 UTC | Add test of Cmp.EQUAL with array value This test fails currently For #878 | 17 December 2014, 17:36:49 UTC |
| e911195 | Dan LaRocque | 17 December 2014, 15:37:41 UTC | Add Cardinality & Multiplicity enum shell imports The Cardinality.* and Multiplicity.* enum names are now imported automatically in gremlin.sh and rexster-console.sh as distributed with Titan. For #869 | 17 December 2014, 15:37:41 UTC |
| 1f6f950 | Dan LaRocque | 17 December 2014, 14:24:38 UTC | Support ThreadLocal and CHM for Kryo caching This commit adds the `graph.kryo-instance-cache` option. It takes either the value THREAD_LOCAL (default) or CONCURRENT_HASH_MAP. This commit effectively restores the old Kryo caching behavior of KryoSerializer, where it stored Kryos in a ThreadLocal, and where those ThreadLocals are not necessarily removed when Titan shuts down. The CHM setting provides an alternative that, unlike ThreadLocal, is exposed to synchronization overhead when retrieving cached Kryos, but which also releases all of its cached Kryo references when the graph is shutdown. For #840 | 17 December 2014, 14:24:38 UTC |
| 8d4cb4c | Dan LaRocque | 16 December 2014, 19:49:48 UTC | Tweaking ThreadLocal comment | 16 December 2014, 19:52:08 UTC |
| ab8f6e5 | Dan LaRocque | 16 December 2014, 15:22:31 UTC | AsciiDoc for new ES index creation customization This documents the changes in 6569f8b060a86a6291326e76f5dbe612732b2f7f and f3f79b6120736d30f442f78d59eb62efe8a8d4dd. It doesn't mention the sleep time setting introduced in 979eb87d89bd019f20f82ed6ebf98842a24d3f2c. For #840 | 16 December 2014, 15:22:31 UTC |
| f3f79b6 | Dan LaRocque | 16 December 2014, 14:33:43 UTC | Deleting the ES index creation conf-file option This option was analogous to the client settings conf-file option, except this one controlled settings specific to the request Titan sends to create an index in ES. Not worth adding another conf-file option for this, particularly before the relative-path hack for conf-file options is cleaned up and integrated into the ConfigOption system. For #840 | 16 December 2014, 14:43:58 UTC |
| 6569f8b | Dan LaRocque | 16 December 2014, 14:15:48 UTC | Add ES replica/shard count options This allows the Titan configuration to supply arbitrary key-value settings passed to the Elasticsearch cluster when creating an index during DB bootstrap. This commit reuses the configuration handling code introduced in 304f14e44f986e806ac8e86437ff7b8e46a68045, except this commit controls index creation settings, whereas that prior commit controls client settings. This commit introduces two new config elements: * index.[X].elasticsearch.create.ext (namespace) * index.[X].elasticsearch.create.conf-file (string opt) This commit also changes the option named index.[X].elasticsearch.index-creation-sleep (just introduced in 979eb87d89bd019f20f82ed6ebf98842a24d3f2c) to index.[X].elasticsearch.create.sleep. For #840 | 16 December 2014, 14:20:20 UTC |
| 979eb87 | Dan LaRocque | 16 December 2014, 12:51:01 UTC | add cfg opt for sleep time after ES index creation The Elasticsearch adapter had a hardcoded 200 ms sleep after creating an index. This is now configurable through index.[X].elasticsearch.index-creation-sleep. The default remains unchanged (200 ms). | 16 December 2014, 12:51:01 UTC |
| d42cb26 | Dan LaRocque | 16 December 2014, 12:20:56 UTC | Remove unused field in KryoSerializer c4c72ab3d978f5a5a8515365ecc429fe70215b02 appears to have removed the last use of KryoSerializer's private 'registrations' field. It's not used as of this commit. | 16 December 2014, 12:20:56 UTC |
| 9d1bdc1 | Dan LaRocque | 16 December 2014, 11:46:26 UTC | ThreadLocal cleanup This commit removes ThreadLocal usage from KryoSerializer and CTConnectionFactory. The KryoSerializer ThreadLocal caused problems with Tomcat (#877). CTConnectionFactory's ThreadLocal seems to produce a unmeasurably-small performance gain, if it produces one at all, so I replaced it with an ordinary private final field. | 16 December 2014, 11:46:26 UTC |
| f25f02e | Dan LaRocque | 11 December 2014, 19:57:35 UTC | Disable Faunus type checks when guessing schema FaunusElement does some cardinality/multiplicity integrity checks when adding relations. These are not meaningful when the cardinality/multiplicity of a type is unspecified, such as when reading from N-Triples and writing to SequenceFiles. This commit disables the checks by default. They can be reenabled when writing to a Titan output format, though the checks are not a complete data integrity guarantee when batch-loading is enabled. In particular, it's still possible to violate a uniqueness constraint on a property key when batch-loading is enabled and the Titan-Hadoop schema checks are enabled. | 12 December 2014, 12:02:50 UTC |
| 210efc0 | Dan LaRocque | 10 December 2014, 11:19:07 UTC | Revert "Make Faunus pkeys Cardinality.LIST by default" This reverts commit 70af3f9b5cf9b2811f3aa33aadfec4b51d5aca07. The reverted commit caused a plethora of test failures, all variations on an expected value X in a test method mismatched against the actual value of a-list-containing-X. | 10 December 2014, 11:19:07 UTC |
| 70af3f9 | Dan LaRocque | 10 December 2014, 04:55:28 UTC | Make Faunus pkeys Cardinality.LIST by default These were Cardinality.SINGLE by default before, which maps to Multiplicity.MANY2ONE and could lead to bizarre schema enforcement failures even in workloads that had no explicit schema (such as reading N-Triples and writing SequenceFiles). These keys are now LIST/MULTI by default. | 10 December 2014, 04:55:28 UTC |
| f39fae8 | Dan LaRocque | 26 November 2014, 14:35:07 UTC | Updating some Gremlin snippets in the docs for 0.5 The most important change in this commit is replacement of some Gremlin `(iterable of vertices).type` calls with `(iterable of vertices)*.getVertexLabel()`. I also ran through the getting-started steps in the intro again on 0.5 and copy-pasted the output as it appears today: type=foo no longer appears in `map` output, calling `map` on a single vertex lists each property on a separate line (used to be all on one line enclosed by curly braces apparently), and edge toStrings are formatted slightly differently. The rest of the changes should just account for different vertex IDs than used to be assigned in the getting-started scenario. | 26 November 2014, 14:35:07 UTC |
| 9489245 | Dan LaRocque | 25 November 2014, 20:28:10 UTC | Merge branch 'boorad-titan05' into titan05 | 25 November 2014, 20:28:10 UTC |
| 15b557a | Dan LaRocque | 25 November 2014, 20:21:46 UTC | Merge branch 'titan05' of github.com:boorad/titan into boorad-titan05 | 25 November 2014, 20:21:46 UTC |
| b804fd7 | Dan LaRocque | 25 November 2014, 18:35:42 UTC | Tweak traversal as directed by @dkuppitz New traversal snippet uses the start-dot operator: http://groovy.codehaus.org/Collections#Collections-Gettingefficientwiththestar-dot%27*.%27operator | 25 November 2014, 18:35:42 UTC |
| 6d91a61 | Dan LaRocque | 24 November 2014, 18:18:59 UTC | Add 0.5.2 to compat manifest | 24 November 2014, 18:18:59 UTC |
| 4086937 | Dan LaRocque | 24 November 2014, 18:18:59 UTC | [maven-release-plugin] prepare for next development iteration | 24 November 2014, 18:18:59 UTC |
| 9b6056d | Dan LaRocque | 24 November 2014, 18:18:59 UTC | [maven-release-plugin] prepare release 0.5.2 | 24 November 2014, 18:18:59 UTC |
| e721f73 | Dan LaRocque | 24 November 2014, 18:17:59 UTC | Updating titan.compatible.versions prop | 24 November 2014, 18:17:59 UTC |
| 322b918 | Dan LaRocque | 24 November 2014, 18:14:04 UTC | Add sleep to testIndexQueryWithScore ES rebuilds indexes asynchronously, but testIndexQueryWithScore commits and then immediately tries to search on what was just committed. Maybe we should change the ES test config to force an inefficient full refresh on every write for testing purposes. For now, I'm adding a sleep to the test instead. | 24 November 2014, 18:17:19 UTC |
| ea126c7 | Dan LaRocque | 24 November 2014, 16:49:10 UTC | Merge branch 'issue_808' into titan05 | 24 November 2014, 16:49:10 UTC |
| 2182eb8 | Dan LaRocque | 24 November 2014, 14:10:51 UTC | Set 0.5.2 release date in upgrade instructions | 24 November 2014, 14:10:51 UTC |
| 1e11c64 | Dan LaRocque | 24 November 2014, 14:09:54 UTC | Make release.sh push HTML documentation to S3 | 24 November 2014, 14:09:54 UTC |
| 9fc802d | Dan LaRocque | 24 November 2014, 14:08:52 UTC | Bring release instructions up-to-date | 24 November 2014, 14:09:27 UTC |
| 16f1fae | Dan LaRocque | 24 November 2014, 13:54:47 UTC | Tweak gh-pages-update.sh This script generates a new gh-pages index.html and copies javadocs for the release to /javadoc/$VERSION/ and /javadoc/current/. This commit makes its detection of whether the gh-pages branch already exists more robust by using a git plumbing command instead of checking file existence in the .git directory. Also fix outdated wording talking about wikidoc in one of the messages it prints to console. | 24 November 2014, 13:54:47 UTC |
| 9dcf945 | Dan LaRocque | 24 November 2014, 13:46:38 UTC | READEish file updates for 0.5.2 | 24 November 2014, 13:46:38 UTC |
| 6205f7f | Dan LaRocque | 24 November 2014, 13:23:03 UTC | Remove Maps.immutableEnumMap call For #844. Guava 11 doesn't have this method, so it throws NoSuchMethodError on Hadoop clusters. Changed to ImmutableMaps.copyOf. | 24 November 2014, 13:23:03 UTC |
| 33fe2f0 | Pavel Yaskevich | 24 November 2014, 08:48:41 UTC | use "q=" to set conditions instead of "fq=" for Solr (issue #808) | 24 November 2014, 08:48:41 UTC |
| 34002ea | Dan LaRocque | 23 November 2014, 13:43:39 UTC | Support titan.hadoop.output.location Fix #822 | 23 November 2014, 13:45:08 UTC |
| 66a60a9 | Dan LaRocque | 23 November 2014, 13:42:36 UTC | Adding test of titan.hadoop.output.location For #822. output.location was recently removed and jobdir.location added instead, so this test of output.location currently fails. Reimplementation of the expected (pre-0.5) output.location behavior coming next. | 23 November 2014, 13:44:18 UTC |
| 274af8b | Dan LaRocque | 23 November 2014, 13:13:56 UTC | Merge branch 'titan05' of github.com:thinkaurelius/titan into titan05 | 23 November 2014, 13:13:56 UTC |
| 5a853d7 | Matthias Broecheler | 23 November 2014, 03:03:29 UTC | Support for Contain.IN in queries-centric queries with test coverage. Addresses the second part of #679. Fixes #679. | 23 November 2014, 03:03:29 UTC |
| 8fe79b1 | Matthias Broecheler | 23 November 2014, 00:29:57 UTC | Support for Contain.IN in Vertex-centric queries with test coverage. Addresses the first part of #679 | 23 November 2014, 00:29:57 UTC |
| 8d543a9 | Dan LaRocque | 22 November 2014, 22:27:51 UTC | Fix test excludes in titan-hadoop-parent This change should have been part of 856a84ee55aa106d29db3d6ade540b7ca627dd57 | 22 November 2014, 22:27:51 UTC |
| fb704eb | Matthias Broecheler | 22 November 2014, 04:50:52 UTC | Merge branch 'titan05' of https://github.com/thinkaurelius/titan into titan05 | 22 November 2014, 04:50:52 UTC |
| cfbe4c8 | Matthias Broecheler | 22 November 2014, 04:50:40 UTC | Added a test case to verify that concurrently updating low-selectivity index entries while reading from them causes result duplication because of query limit adjusting. Added configuration option to disable this behavior. Fixes #839 | 22 November 2014, 04:50:40 UTC |
| 90c2cd4 | Dan LaRocque | 21 November 2014, 20:29:38 UTC | Merge branch 'titan05' of github.com:thinkaurelius/titan into titan05 | 21 November 2014, 20:29:38 UTC |
