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.
Related
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
I've been programming in Rails for about 7 months now. Mainly an app to aministrate a database, you know, clean up, update, delete, find orphaned entries etc.
I have an API that talks to our desktop programs written in PHP. We now find ourselves wanting to move everything over to Ruby. This API needs to be lightning quick and will not have any views or HTML pages of any sort, it will only communicate with our apps via JSON, sending and receiving data that the apps will then display and work with.
So, the basic question is, should I learn Sinatra and Padrino (with ActiveRecord) and build the API with them, or do it in Rails?
If I use Rails I could keep a lot of the code I have or even use the existing code since all the tables are the same (database is the same) and just write more methods for the API.
The downside I see to this is twofold:
It means the code is harder to manage and read because now we have the API bit and all the maintenance bit.
It would mean that the same Ruby app is doing double work so the API would not be as fast as if it were running in another, separate Ruby app.
Already the Rails app is not great speedwise but I suspect this has more to do with our hosting solution than Rails itself.
Learning Sinatra and Padrino might be more work, but would lead to cleaner code and a separate Ruby app for the API and another one for the maintenance which sounds nicer.
But I don't know anything about Sinatra and Padrino, is the footprint and speed really that better than Rails?
I would greatly appreciate opinions from people who have actually used both Rails and Sinatra with Padrino on this.
Cheers.
Sinatra and Padrino are not automatically faster than Rails. They are just smaller than Rails (and supply the developer with a smaller, more focussed toolkit). Application speed mostly depends on your code (and algorithm). The same is often true for elegance, maintenability and other aspects.
If you already have good, maintenable code that runs on Rails, most likely you should just improve it. Make it faster with a good hosting/caching solution and keep it elegant and maintenable with refactoring.
Nowadays, both Rails and Sinatra offer very good support for the development of RESTful webservices and, more generally, for the development of UI-less APIs. Rails is just larger and takes more time to be tamed but, luckily, you do not have to study and use all of this behemot to get your job done. An application running on Rails can be as fast and elegant as one running on Sinatra because the Rails subset actually used to handle REST requests is as small and elegant as the whole Sinatra framework. Hence, application speed mainly depends on your code and on your hosting/caching choices.
On the other side, you ought learn Sinatra and Padrino in any case. These frameworks are two of the most elegant and fascinating pieces of software I have ever seen. They absolutely deserve your attention. Just keep in mind that Sinatra, used alone, is normally not enough for anything more complex than a UI-less RESTful API. Most likely a real, full-blown web application will require Padrino.
If you have an existing Rails app already, it might be easier to port it over to rails-api. It's basically just Rails but stripped of all components used in making UIs.
I haven't personally used it but I was evaluating it for a project a few months ago.
Are there any web frameworks on top of EventMachine? So far, I've found Fastr and Cramp. Both seem to be outdated.
Moreover, Googling how to setup Rails + EventMachine, returns a limited amount of results.
NodeJS is really nothing new. Evented I/O has been around for a very long time (Twisted for Python and EventMachine for Ruby). However, what attracts me to NodeJS, is the implementations that are built on top of it.
For example. NodeJS has TowerJS. Among plenty others. Perhaps, this is one of the many contributing reasons to its trending factor.
What I like most about TowerJS, is its Rails-like structure. Is there anything like it for EventMachine?
Goliath is an open source version of the non-blocking (asynchronous) Ruby web server framework.
You may find async sinatra interesting
Besides EventMachine and the others mentioned here, there's vert.x. I'm not sure how much of a "web framework" it is, but its site shows examples for a simple app like one might write in Sinatra.
I'm starting a new project and I have maybe three resources defined. Not a lot of code so far. (Rails 3.1)
But I'm interested in trying out DataMapper. I'm used to ActiveRecord (and actually enjoy it) but I'm always on the lookout for new things. Plus, my application uses Backbone.js but I don't believe that's relevant.
So how hard is it to switch out the ORM "mid-app" like this and do you think the learning curve to DM is that hard?
PS, there is a chance that I might be using other engines alongside my application. Such as MongoDB running along with Postgres. Will DM be at an advantage there?
To use Datamapper itself, there isn't much to it but it is some of the Rails niceties that require additional work (like the SQL execution times in "rails s") and there is also the rake tasks.
Check out dm-rails - They have a template that you use to provision the initial Rails project that sets it up with everything for Datamapper. You can also look through the source and see how it hooks everything. There is a small issue if you use database-backed session stores with Datamapper, which involves a monkey patch.
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.