Gremlin - gremlin queries in tinkerpop documentation not working - graph-databases

I am new to graph databases, gremlin and tinkerpop. We are using them in an application we are building and the setup has been done by some other team.
Now when I try to run the gremlin queries provided in the tinkerpop documentation, many of them are not working and I am getting errors saying 'no signature of method:'.
Can you please guide me on what and how to check, either versions or anything else to make them work.
We are using janusgraph, cassandra as storage backend and elasticsearch for indexing.

Checking the version of Gremlin as you did was the right path to take. There may be minor differences between "z" versions of x.y.z and larger differences between "y" versions of 'x.y.z'. So for 3.2.3 you would want this documentation for TinkerPop:
http://tinkerpop.apache.org/docs/3.2.3/reference/
As of this writing, JanusGraph has not yet released a version with TinkerPop 3.3.0 support and my sense is that it is not quite as trivial as just bumping the version number. 3.3.0 introduced a number of changes that graph providers would likely have to deal with in the form of new test, revised semantics, class renaming, etc. It's not something you would likely be able to do on your own without prior knowledge to how JanusGraph works.
There does appear to be a pull request for 3.3.0 support however so you could try to build that if you'd like an early look at how it works. If not I suggest you consult the 3.2.3 documentation and simply write your Gremlin in that form. 3.3.0 doesn't really introduce a ton of major new Gremlin steps, so you aren't missing much - I think you only get limit() and better addE() semantics. I would be sure to consult javadocs of 3.2.6 for a full list of every Gremlin step that is deprecated so that when JanusGraph does release 3.3.0 support, you are in the best position to upgrade.

Related

What version data store does Gremlin create when creating a Neo4j database from the console?

Im running Gremlin v 3.2.5, and I keep getting errors when i try to connect to a Neo4j database from the Gremlin console, or using the neo4j-gremlin API:
Failed to start Neo4j with an older data store version. To enable automatic upgrade, please set configuration parameter "allow_store_upgrade=true"
I create the Neo4j database using the neo4j-java-driver 1.4.3, and neo4j 3.2.3, like so in scala:
val graphDb = new GraphDatabaseFactory().newEmbeddedDatabaseBuilder(new File(dbPath))
.setConfig(GraphDatabaseSettings.allow_store_upgrade, "true").newGraphDatabase()
or in the Gremlin console
gremlin> conf = new BaseConfiguration()
gremlin> conf.setProperty(Neo4jGraph.CONFIG_CONF + "dbms.allow_format_migration", "true")
gremlin> g = Neo4jGraph.open(conf)
So I would like to know what version datastore Gremlin uses because it doesn't seem to matter how I make the DB, I get errors like the one above. I believe my version of Neo4j creates a datastore v0.A.8, and the only thing I haven't tried, which may work, is downgrading my version of Neo4j. Thanks in advance for any Ideas/feedback!
*edit: gave wrong version number of neo4j-java-driver, added neo4j version
tldr; Apache TinkerPop 3.2.5 is tested to work with Neo4j 2.3.3.
It's worth noting that there is no direct or default dependency on Neo4j for Apache TinkerPop, given the GPL licensing of Neo4j which conflicts with the Apache license. So there is a bit of indirection involved in determining the version to deal with. Technically, TinkerPop leaves it to the user to choose the version of Neo4j to use by selecting a version of neo4j-tinkerpop-api-impl:
https://github.com/neo4j-contrib/neo4j-tinkerpop-api-impl
that is compatible with the version of neo4j-tinkerpop-api
https://github.com/neo4j-contrib/neo4j-tinkerpop-api
that is used with the version of TinkerPop that you are using. In the case of 3.2.5, that would be:
https://github.com/apache/tinkerpop/blob/3.2.5/neo4j-gremlin/pom.xml#L41
While you are technically free to choose a version of neo4j-tinkerpop-api-impl it's worth noting that TinkerPop 3.2.5 is only tested against 0.3-2.3.3 which is hooked to Neo4j 2.3.3:
https://github.com/neo4j-contrib/neo4j-tinkerpop-api-impl/blob/0.3-2.3.3/pom.xml#L23

which is the most stable and tested version of apache solr on hdfs or maprfs

I am trying to setup solr in my project, want to know which is the most stable and tested version of solr available. I want to use mapr filesystem.
Basically, there are two rules for all Solr releases:
They all have a large number of tests to pass before release.
Still, there's some issue with every .0 release, so it's wise to choose the bugfixed .1 even later releases.
Bonus: This applies to every type of file system you want Solr to run on.
Then there is a trade-off between having the latest features and having it around in field use for longer time. Of course, version 3.6 was thoroughly tested in the field, because it's been around for many years. But it's so outdated you should not choose it. The same applies for the 4.x branch.
On the other end, there's the 6.x branch which has many cool new features but is relatively young. So personally, I recommend you to go with the latest release of the 5.x branch. While the 5.0 release had many new features introduced, the work up to the latest released version 5.5.4 had many fixes applied and still gets backports for things that are fixed in the 6.x branch.

Configure SOLR indexing with AEM 6.1

I am trying to configure SOLR indexing with AEM 6.1 but struggling with the following: -
What type of installation should be used for SOLR (embedded v/s
remote).
How to configure the selected installation with AEM 6.1.
How to determine whether the indexing has been successfully done.
Any help would be extremely appriciated.
I did lot of research on SOLR with AEM 6.0. I think I can answer to your question.
It depends on what are the requirements of the client. If the clients needs a quick search response and it have lot of content, you should prefer remove vs embedded. If the site has small content, the embedded could be sufficient. The remote permit to have a sharded cluster, so you can optimize the concurrent search response by adding more shared
The documentation of AEM is pretty well documented about this. You can find here: https://docs.adobe.com/docs/en/aem/6-1/deploy/platform/queries-and-indexing.html
Finally you can see the indexation well configured by enabling the logging configuration about the search (Look for to Enable Logging in the previous URL). You can test your search with tool in the ACS-Common with tools in ACS-Tools (http://adobe-consulting-services.github.io/acs-aem-tools/)
Hope this will help you.
Stéphane
I've stumbled upon these projects, as I searched for AEM Solr integration:
https://github.com/headwirecom/aem-solr-search
https://github.com/infielddesign/aem-id-solrindexer
Maybe it will help you with the Solr integration and configuration.
And as already mentioned above, the type of installation highly depends on your customer requirements.

serviceMix 4.4 does not support ODE any longer, what is the alternative way to do orchestration?

I am new to serviceMix, I downloaded serviceMix 4.5.1 a couple of days ago.
When I tried to install ode in serviceMix using the command
features:install ode
It tells me this:
Error executing command: No feature named 'ode' with version '0.0.0' available
I googled/baidued mass of webs, I got a bad news that:
"Fuse ESB 4.4 does not support Apache ODE. The latest version of ODE is not compatible with Fuse ESB."
which comes from
http://fusesource.com/forums/thread.jspa?messageID=11209
Fuse ESB - ODE installation
So if serviceMix 4.4 does not support ODE any longer, what is the alternative way to do the web service orchestration in serviceMix? I have tried use camel to do this work,but that's not easy.
How about "bpel-g"?(http://code.google.com/p/bpel-g/) is it a good choice? or any other choice?
Any help will be really appreciated.
I like Activiti for processes and orchestration.
Never run it inside Karaf/SMX/Fuse ESB but it should be possible, if not using this instruction.
It also has a nice web explorer for human tasks etc. if you need it and BPMN modeller for rapid desing and visualization
I would recommend to try bpel-g. A colleague and me have been doing some BPEL conformance benchmarking lately (fyi: the benchmarking tool is available at github) and bpel-g turned out have the highest degree of support for the BPEL spec., along with the older ActiveBPEL engine from which bpel-g is a fork. ODE ranked third place.
Another nice feature of bpel-g is that it is indeed actively maintained. I don't know how well it integrates into the infrastructure of Fuse ESB, but since it's deployable as a war, this shouldn't be much of a problem.
UPDATE: Just had a look up: bpel-g seems to integrate with camel and provides a custom handler to invoke camel components. So, basically, the solution outlined in Petters answer also applies to bpel-g and, in contrast to Activiti, it has a message correlation framework. Finally, the barrier to using it should be smaller, as you already know BPEL. As a consequence, bpel-g might be a more suitable solution here.

Migrating from Cake 1.3 to 2.0 and beyond - migrate existing, or only use for new?

I'm nearling completion of my first CakePHP-driven website and just saw they're already working on CakePHP 2.0 (not the stable release yet).
My questions:
Is it incredibly time consuming to move to a new version of CakePHP (when it becomes the "stable" release that is)? I know they have migration guides, but - I've never used a framework before, so I've never had to migrate anything.
Do you migrate your code for existing projects, or leave it as is and use the new stable version for future projects only?
Where can I find what version of CakePHP I currently have installed? I've looked at the LICENCE and VERSION files, but cannot find the installed/current version listed in them.
These seem like simple questions, but I greatly appreciate any thoughts/advice - searching this on Google just brings up how-to-migrate pages, not pros/cons...etc.
I've migrated a few sites from CakePHP 1.2 to 1.3. In my experience, it takes 2-3 hours on sites that have 5-10 controllers and no custom plugins, etc. I find I typically only have to change the syntax on a handful of function calls, and when I figure out which ones, it is just a matter of doing a find / replace across the site. Of course it could be more of an issue going from 1.3 to 2.0, but I don't get the sense that it will be an especially drastic API change.
UPDATE: I'm now in the process of migrating to CakePHP 2.0 beta, and thought I should update this, as I'm finding the updates are more extensive and far-reaching than I had assumed when I wrote this. Migration guide here: https://github.com/cakephp/docs/blob/master/en/appendices/2-0-migration-guide.rst
ANOTHER UPDATE: Since people seem to be finding this useful, I just thought I'd point out that Cake now helpfully provides an upgrade shell that does some of the work for you. Note that although the documentation says it will do "most" of the work, I have found there are still quite a few function calls, etc. that will need to be updated manually (see migration guide).
http://book2.cakephp.org/en/console-and-shells/upgrade-shell.html
As dhofstet said, it will all depend on the size and complexity of your site.
Whether you upgrade at all is usually a judgment call, but sometimes you have to (e.g. Cake 1.2 has some code that will break if your host upgrades to PHP 5.3). You certainly wouldn't have the kind of security issues that an old WordPress, Drupal, etc install would have. I have seen some noticeable speed increases with Cake upgrades, so depending on the situation it could be worth the trouble just for that (Cake 2.0 finally drops PHP 4 suppport). Look at the release notes and see if there are things that appeal to you in the new version.
To see your version, in the cake/VERSION.txt file, look at the very last line. It's easy to miss, but it should just be a number, e.g. 1.3.8.
This question is difficult to answer as it depends on the size and complexity of your project(s). The "big" releases (from 1.1 -> 1.2, 1.2 -> 1.3, 1.3 -> 2.0) usually break stuff and so you have to budget some migration work. The migration between "smaller" releases (for example from 1.3.9 to 1.3.10), on the other hand, is usually easy, often it just means to replace the cake folder. In both cases it is useful to have tests.
I migrate the projects which are actively maintained.
You can find the CakePHP version in cake/config/config.php
I'm migrating an app 1.3»2.0rc1 right now and I got no big trouble.
I had to change names of folder/files, eg. app_controller.php » Controller/AppController.php
Follow the migration link (tmp link) http://book2.cakephp.org/en/appendices/2-0-migration-guide.html
plugins/components/.. from various source won't work (at minus, for point 1)
To update the code (which in my case wasn't needed as the app worked well) I've shell-baked a dummy table and looked at differences in code.. It's a good starting point
Authentication/Authorization changed in some config, but requires few changes.
Trees still working
Acl don't. But I'm quite sure it's my fault.
For now it's all, good work!

Resources