One of the nice features of Solr is its ability to import sql data. However its feature is removed in the bundled version in Datastax. Manually adding the missing jar to $SOLR_HOME/lib and configurations files only make it appear in the Solr portal page, but it still does not work. Datastax is hiding Solr log to some unknown place not documented in its official doc, making troubleshooting more difficult. Has anybody been able to make it work?
Sorry for the inconvenience, but the current releases of DataStax Enterprise do not support the Solr Data Import Handler. This is a known problem. We expect to have it fixed in an upcoming release (likely in a 3.2.x release.)
DataStax Enterprise tightly integrates Solr, so there are configuration differences that need to be taken into account when configuring plugins for Solr. Configuring of DIH will be fixed and documented in an upcoming release.
Related
In upgrading from SCDF 1.1.1.RELEASE to 1.2.4.RELEASE, are there any database schema changes that I would need to be concerned about?
Specifically, if I'm already running SCDF 1.1.1.RELEASE on a Pivotal Cloudfoundry platform, and using a MySQL service tile as the underlying database, will the stream, app, and task metadata that is already in the database translate readily to SCDF upgraded to 1.2.4.RELEASE?
What other potential concerns might I need to take a close look at as I plan to upgrade?
Yes, as documented on the official docs: https://docs.spring.io/spring-cloud-dataflow/docs/1.2.3.RELEASE/reference/htmlsingle/#configuration-rdbms
Apart from the migration-script, there shouldn't be any other concerns wrt upgrade. At least in 1.1 -> 1.2, there's simply a case-conversion of a Task table name, which shouldn't impact existing records or any other functionalities.
That said, 1.2.4 is an old release. Please consider switching over to 1.3 GA release at the earliest. This release includes migration scripts as well, but again, we make sure to not introduce breaking changes in the minor releases (e.g., 1.2 -> 1.3), so switching to 1.3 should be straightforward.
Here's a roundup of all the new features available in the latest 1.3 release.
I have found some relevant modules on Github but they do not work.
Does anyone know of some other available solutions?
Those are the three I have tried:
https://github.com/bobby/node-neo4j
https://github.com/gasi/node-neo4j
https://github.com/neo4j/neo4js
Go with the repo made by the people who make Neo4J: https://github.com/neo4j/neo4js
Like I mentioned, it is created and maintained by the people behind Neo4J and is constantly updated. I am using this currently in a project and it works fantastically well. Only thing to know is that you need to be running Node.JS 1.6 or better for the modules to work.
If you have any questions drop me a line or you can also ask in their discussion forum here: http://neo4j.org/nabble/
I'm one of the authors/maintainers of #gasi's node-neo4j (npm install neo4j). We have admittedly not upgraded it for 1.6 (we're still on 1.4 here but plan on upgrading soon), but it works entirely well -- we've been using it on our production site for many months now!
Can I ask what the issue is? Btw, we moved the repo to our formal organization's repo: https://github.com/thingdom/node-neo4j
Take a look at: https://github.com/philippkueng/node-neo4j
npm install node-neo4j
We're currently working on an upgrade to Neo4j 2.0.
It will support insert node with label, indexes on labels, CRUD for labels, constraints and streaming.
My work in progress (fork): https://github.com/Stofkn/node-neo4j
STS is over 350MB and most of it is corporate blubber ware that I do not need. For example its default installation includes bunch of Servers that shows up in project explorer and other things related to VMware cloud related products. All I need is Grails and Groovy and JavaScript related development and nothing else.
What is the procedure to remove all these things for clean and light installation of STS without destabilizing STS?
You can choose not to install tc server, Spring Roo and Apache Maven during the install. Also, you can go under Help -> About SpringSource Tool Suite, click Installation Details..., and uninstall plugins you don't want.
I know this question is already answered, but I just wanted to mention another way of installiong STS. You can do this through update sites. This way is slightly more complicated (only slightly), but does have the smallest footprint. You can see the instructions here:
http://blog.springsource.com/2011/03/25/early-access-springsource-tool-suite-for-eclipse-indigo-3-7/
I've been developing a web application and a lot of customers are asking if they can host the application in their network (for security reasons). I have been looking for a way to package up a rails app into a single executable (with server and all), but haven't been able to find anything. My other requirement is that we distribute it without the source. Because of that I was looking at JRuby and Warbler. The end product should run on linux or windows. Has anyone done anything like this before, or can anyone point me in the right direction.
Thanks
My best guess would be to use JRuby and the JRubyCompiler, although I have no idea if you could compile a whole rails project (including all the required gems). I got it to compile a small ruby script though. Anyway, if you succeed, you could package those in a jar or war and deploy that as a contained application.
It doesn't sound like you necessarily need to package it as an executable, as long as the code is obfuscated. I personally haven't needed to protect any of my code, but a quick google search returned this product http://rubyencoder.com/. I'm sure there are others out there, but the basic idea is that your code is unreadable and cannot be reverse engineered. This would allow you to run a standard rails environment without giving access to your source code.
If you have the budget and really want to outsource this, the Github guys partnered with BitRock to build their cross-platform installable product (Github Firewall Install). BitRock has this case study on their website.
Have been developing with Grails for couple of weeks now,
Though I've loved the experience and the possibilities, I've seen following problems starting up.
Please share if you've had similar issues.. and remedies would help too.
Transaction management (in-built) doesn't seem to work in some circumstances.
AOP with domain objects doesn't work
Grails IDE-plugins are pretty primitive
GWT-Integration (with the plugin)
Plugin installation (fails unusually) probably cause plugins are not matured enough.
Lack of extensive documentation (though what is available is pretty good)
Debugging support
If you actually want solutions for these problems you should post a separate question for each with a lot more information than you've provided here. For example, I can't possibly diagnose the cause of the problem when all I know is
Transaction management (in-built)
doesn't seem to work in some
circumstances.
Here is my opinion on these issues:
Transaction management (in-built) doesn't seem to work in some circumstances.
I haven't noticed any such problem
AOP with domain objects doesn't work
I guess what you mean here is that meta-programming domain objects doesn't work. I have encountered this and haven't found any solution. If you really meant AOP then I can't help you as I've never used it with Groovy.
Grails IDE-plugins are pretty primitive
The IntelliJ plugin is very, very good. The Netbeans plugin is OK. Last time I tried the Eclipse Groovy plugin it was awful. However, I believe that a new Eclipse Groovy plugin has recently been released as part of the Spring Tool Suite (STS). It's supposed to be big improvement on the previous Eclipse Groovy plugin, but I don't think it has much Grails support yet
GWT-Integration (with the plugin)
I don't use GWT, so have no comment
Plugin installation (fails unusually) probably cause plugins are not matured enough.
I've never had problems installing plugins, though if I update a plugin, I sometimes need to manually remove the old version from the .grails directory.
Lack of extensive documentation (though what is available is pretty good)
I think the level of documentation for Grails is way ahead of most OS projects. There is a wide range of Grails books available, there's an active mailing list, and the official document is 176 page long.
Debugging support
Again, it depends on the tools you're using. With IntelliJ, debugging a Grails app is as easy as debugging a Java app with Eclipse.
My own pet peeves about Grails development are:
Upgrading from one version to another is often a very painful process due to lack of backward compatibility. When I upgraded from 1.0.4 to 1.1.1 about 20% of my tests started failing
Application reloading is very hit and miss.
My feedback after few months with Grails:
Didn't happen to me.
I don't use AOP
Wrong. IntelliJ is very good and especially the last beta version. You can download it for a free trial. I know that Eclipse support is very limited and NetBeans becomes better but still behind IntelliJ
I can't say. I don't use it
Agree. My piece of advice here is to follow these following principles: 1.Use plugins as few as you can. Your application will be lighter and more maintainable. Also, you will upgrade Grails version more easily. 2.if you want to use a plugin, test it before with a dummy project. It takes few minutes for creating a grails application and you could test your next plugin rapidly. Be aware that sometimes plugins have compatibility issues between theselves so, do not hesitate to install all of the plugins you need into your dummy project
Agree. Grails is a very complex framework and documentation does not cover every aspect of Grails. But what is available is well explained. Also, grails community is very responsive, so if you don't find something you will easily have an answer in Grails forum or even on StackOverflow
Definitely Agree. Again, with IntelliJ you can debug easily but it is resource-consuming and takes time when reloading your app. So usually, I end up with logging traces and I debugg my full stack of exceptions like that! IMHO, this is one of the major shortcomings of Grails.