I want information about the ar-extensions gem work on postgresql-8.4.If it works means please give some related information
It should work (as in the API should be fine), but it doesn't provide any performance boosts as I did not regularly or actively use postgresql back then and still haven't built postgresql optimized functionality. I am waiting for a postgresql user to submit a patch or at least show me what the "postgresql" efficient way would be, but to this day I have yet to see either from the postgresql crowd.
Please note that ar-extensions should only be used for Rails 2.x and activerecord-import should be used for Rails 3.x. Also, the finder extensions available in ar-extensions are no longer supported in activerecord-import so those definitely won't work.
Related
I plan to use Elasticsearch on heroku.
I was looking for the best option of Elasticsearch add-on I can use.
Found was my first choice from the following reasons:
It is now part of elastic.
When using Elasticsearch on heroku it will be opened to the world - a secure wrapper to the transport client was introduced - https://github.com/foundit/elasticsearch-transport-module/
But it looks like this repository is not highly maintained, and Elasticseach 1.5 is the latest version which is supported.
What is the recommended add-on then?
If I want to use the latest version of Elasticsearch I am doomed to use an unsecure connection?
Maybe use the official java client?
Nick with Bonsai here. Based on your question, and my own obvious bias, I'll suggest Bonsai for the following reasons:
All of our clusters have SSL with basic auth to secure the connection. We feel pretty strongly that security comes as a standard feature.
We were the first hosted Elasticsearch provider, ever. (And one of the first addon providers on Heroku, ever, with our first search addon, Websolr.) So we've got plenty of experience hosting search and and thousands of other happy Heroku customers.
One definite tradeoff with using Bonsai is that we're generally always going to lag a bit behind the latest version of ES. As of this posting we're still running ES 1.7, but updates to ES 2.2 are just around the corner.
This is probably going to be true in the future as well. Part of the reason for this is that we're a small, bootstrapped company, and we have to be pragmatic in where we focus our engineering efforts. Plus as an operations company with thousands of businesses, we like to let major new upgrades spend a few months in the wild before we commit to supporting it.
We also work hard on providing managed upgrades, at least for versions that are sufficiently backwards compatible. Everyone has their tools for helping to manage upgrades, but I don't think any of the other providers do actual in-place upgrades.
Unless you have a hard requirement for a specific feature in 2.x (and if you do, please let me know) you may do fine on 1.7 until our 2.x support is fully baked. Drop us a line at info#bonsai.io to get whitelisted for the first release of that in the coming weeks.
Am starting to write unit tests along the lines of https://github.com/neo4jrb/neo4j/wiki/How-To-Test
One of the approaches there is really slow (10 seconds per test) and the other doesn't delete labels (and probably other things)
Can anyone suggest a more elaborate approach? I noticed that in the core neo4j material, the java documentation describes methods that create and tear down temporary databases, but I don't see a way to access those from the (very nice) ruby and rails neo4j gems. Perhaps via the low-level REST api? It's hard to figure out what api calls are available.
So you could probably surround your tests in transactions which is a typical approach for testing with ActiveRecord in Ruby. That might be more performant, but it should also help keep the database clean.
But you're right, the impermanent database is the tool that's provided in Neo4j for temporary databases for testing. I think that's only available if you're running JRuby, though. I did run across this, though:
https://groups.google.com/forum/#!topic/neo4j/7xeEPWEiqD0
Which links to a project which lets you start up a Neo4j server in "in memory" mode (using the impermanent database):
https://github.com/jexp/neo4j-in-memory-server
That's showing examples for Neo4j 2.0.0, so I don't know if it would work for later versions, but it might be worth a shot for your testing database.
EDIT: Another thing that I just thought of is to use the vcr gem:
https://github.com/vcr/vcr
It basically records all of the requests made to your server and then plays them back. This works great for API endpoints where result are idempotent, but if you use it for a database like Neo4j you should make sure that your tests are clearing the database before every test run so that it always starts fresh
We're going to migrate our application from eXist-db 1.4.1 to ~2.2 (probably RC2).
I`m wondering if anybody already did such a migration and what impediments they met?
I already found some documentation about this on official website and tried to Google, but didn't find much. For now I know that there were significant changes in the security model and some APIs are also changed. But still I want to know if somebody investigated further or maybe can share success story.
The main difference between 1.4.1 and 2.1/2.2 is that stored XQueries now need the executable flag to be set. You can fix your permissions automatically using a query as described in the documentation.
It is also possible that some of your existing queries report errors on 2.1/2.2, which they did not before. In nearly all cases this happens because 1.4 was less strict about the XQuery specification and processed expressions which should not be allowed (the standard as well as the implementation evolved). Also, the query engine may now do additional checks to prevent potential issues. Usually the error messages by the compiler should directly lead to the code you have to fix. This may cost a few minutes, but it's worth the effort. Apart from this, no particular migration issues have been reported.
I'm hoping to introduce a graph DB into my project w/o having to move to jRuby. As I see it, given this restriction I've got two options:
Use a graph DB that provides a RESTful interface. I don't know what impact this will have on performance. I'm planning for a crapload of data.
Find a graph DB that has a ruby interface not requiring jRuby. In my search thus far I've not found anything but most of the posts and blog entries I've found have been fairly dated. I'd prefer the DB and interface to be somewhat mature and reliable, of course.
Does anyone know of anything that would meet #2 above?
If you're concerned about performance, I'd recommend trying JRuby and neo4j.rb
because it interacts directly with the embedded, high performance neo4j-Java-API. Ultimately I think that would be the highest-performance solution.
If you're not willing to entertain JRuby at all, there are options. Neo4j has a REST API and neography is a thin wrapper for it.
Or you use the Neo4j Server - (J)Ruby extension. This is a JRuby Rack application that exposes a REST API. It contains the Neo4J server, so it can be installed and used as a JRuby app, and your stack is Ruby all the way down, even if it is mostly MRI Ruby and the JRuby part is isolated to persistence.
I'm testing a web application with ruby 1.8.7 and WATiR and I'd like to connect to a H2 database as easily as possible, which I can only find info on JDBC access for. If there's a way to use JRuby to do this from Ruby that is okay, but I need to use Ruby primarily because my WATiR code is written in it and will hopefully remain so.
All possible solutions will be considered but I'm looking for some simplicity because my database knowledge is limited and I need to access the database (read from and write to) from Ruby/WATiR to test against what's displayed on the web front end.
EDIT: I removed some of my ignorance, now I know JDBC is a Java API for DB access, so I'm now looking for any way to connect to a H2 database so that my Ruby/WATiR scripts can access it.
Background:
I have some experience with DBI and Sequel gems, and I have Rails installed (so I can start to play with ActiveRecord, mainly), but willing to learn new things to solve this issue.
Let's assume I'm not a great Java coder. I've also never looked into using JRuby before, so I'm not entirely familiar with how it works.
Solution
I eventually got the two talking to each other, mainly thanks to Thomas Mueller's answer below. I installed the PostgreSQL ODBC driver, got Sequel working and connected using ODBC. Using Sequel's PG adapter to connect to the H2 PG server causes some Syntax errors that I'm still working on. I have not yet tried DBI to connect, but I will as it may give me greater control of the syntax should I need it. Many thanks also to Jeremy Evans for his help solving a conflict between activerecord-jdbc-adapter and Sequel (pesky pg.rb file in my ruby path), and for managing Sequel. This is not listed as an answer so that I can give credit to those that answered whilst giving feedback to people in the same situation as me.
I have installed pg (not ruby-pg), sequel, dbi, dbd-odbc (plus a manual file fix, you can ask me for details), hoe, and UNinstalled activerecord-jdbc-adapter.
H2 can act as a PostgreSQL server and supports the PostgreSQL ODBC driver.
So in theory you should be able to use ruby-pg. But I have never tried it myself, I guess the chances that it works are about 50%. So the answer is: maybe. But the preferred solution is to use JRuby.
If WATiR is written in Ruby... then WATiR should also work in JRuby?
there is no such thing named jdbc database, you can access any database using ruby so long as the database provides a ruby connector.
IMHO your two best options are either the DBI or Sequel gems.
The DBI gem can be used to connect to a db via ODBC. If H2 has an ability as Thomas indicates to support ODBC then you should be able to use DBI to connect to and query the db (which of course includes 'update' queries to setup given test data etc).
See the rubyforge DBI Page for more info. DBI has been around a while so it's fairly easy to find online tutorials for how to use it, etc. It is fairly low level, and you need to know SQL or your DB's language, in order to interact well with it.
Another option would be the SEQUEL gem, which has an option to connect via ODBC or JDBC (JDBC has a H2 sub-adaptor). This Gem is newer and offers some specific advantages over DBI. see this link to the Opening_Databases portion of the rdoc files for Sequel where it talks a little bit about using JDBC to connect to databases. I guess which is easier depends on how hard the ODBC is to setup for H2 vs how much Java you have to learn in order to get JDBC working for you. (I'd head for ODBC first if it was me, since I know very little Java)
Myself, I've been using DBI so far (to connect to MS SQL via ODBC), but I have to admit wondering if using the Sequel gem instead might be better. Sequel saves you from writing a lot of actual SQL type code or even having to understand SQL queries in depth, and lets you do everything ruby style using methods, symbols and some strings here and there. If you are doing a LOT of db interaction I can see where it is clearly superior especially in terms of being able to create a lot more pure OOP code. See this presentation by the Sequel author at a Ruby conference in 2009 for more details.
In my case DBI is 'good enough' for what I need since I am very comfortable with SQL, and don't really need to do much other than issue a few commands here and there to do db-level bit-twiddling to create proper test conditions. OTOH if I was having to do a lot of queries against the db as a test oracle and comparing that with data presented in the UI, I can see where using Sequel would make my life a lot easier.