If I use Sequel in a Ruby app like this:
DB = Sequel.sqlite('testdb.db')
does it make the database shared? Can I acces this same file from a different ruby app AT THE SAME TIME and get the database to perform locking etc?
I'm thinking probably not and i'd have to actually have a separate instance of the database running.
Yes, if you use a file backed database, you can access it by multiple processes. They don't even have to be ruby processes. Note that in SQLite, writers block all readers, so multi-process or multi-threaded write performance is not very good.
This is not up to neither Ruby nor Sequel. It's up to sqlite. Take a look at sqlite FAQ, and see whether it answers your question.
Related
We want to use sqlite, via the sqlite3 gem in Ruby in a production app on Heroku. However, heroku detects the gem, and blocks our deploys.
We're aware heroku's filesystem is ephemeral, but we're using SQLLite's in memory mode for a short lived database in a background worker. Heroku blocks the gem because they worry people will attempt to use it as a persistent database and be surprised when their data disappears (see link below). I can appreciate their concern, but we have a legitimate use case, and are still blocked.
Are there are any work arounds to the nanny-check heroku adds if you have a legitimate use case for sqlite?
Edit: Please note, we are not looking for alternative tool suggestions. We already have a "real" database with terabytes of data. We're loading data into a local temp DB as a legit optimization. sqlite lite works great on Heroku using any other language binding. I'm just looking for a way around Heroku's nanny-check to use Ruby + sqlite.
https://devcenter.heroku.com/articles/sqlite3
Unfortunately, Heroku doesn't support SQLite on its architecture basis. You should migrate to PostgreSQL. But I know the solution without migrating - Dokkur - Heroku analogue.
I don't think you have a lot of options here. Heroku doesn't allow the use of SQLite.
You can still use a PG table as a generic, short-lived, database. Or if you just need a simple storage and you don't need advanced querying mechanisms, you can use Redis.
Both are available from Heroku.
I'm used to writing PHP queries to databases (i.e., queries that looks like SQL syntax), but I'm confused on how to do this in Ruby's Sinatra gem.
None of the documentation or tutorials I found online indicate that Sinatra is similar to PHP.
Am I missing something here?
As far as I understand the matter, Sinatra isn't created for database queries. It's a DSL which makes easier creating applications for getting requests from the web-server and forming responses. To work with databases there are two approaches: using the ruby bindings to a database or using ORMs. The last approach is wide spread and preferable in modern Ruby web-development. Here's the list of ORMs which you can use to work with databases making web-applications in Sinatra:
Sequel
DataMapper
ActiveRecord (which itself is the part of Ruby on Rails but you can use it outside the framework)
Say I have some objects that need to be created only once in the application yet accessed from within multiple requests. The objects are immutable. What is the best way to do this?
Store them in the session.
If you don't want to lose them after a server's restart, then use a database (SQLite, which is a single file, for example).
You want to persist your objects. Normally you'd do it with some ORM like Active Record or Datamapper. Depending on what is available to you. If you want something dead simple without migrations and you have access to a MongoDB use mongomapper.
If that object is used only for some time, then it is discarded (and if needed again, then recreated), use some caching mechanism, like memcached or redis.
If setting up such services is heavy and you want to avoid it, and - say - you are using Debian/Ubuntu then save your objects into files (with Marshal-ing) in the /shm device which is practically memory.
If the structure of the data is complex, then go with SQLite as suggested above.
I have a simple Sinatra application that needs some persistence storage. If possible, that database should offer some access by id, and keyword search/find options.
Considering the nature of the to-be stored items, a document-based database seems the best fit.
Obviously I have considered MongoDB and CouchDB, but all have one problem: they introduce dependencies on third party services. I don't want that.
My users should install the Sinatra app as a gem, with its dependencies, run a single command and have everything running.
I am looking for solutions that come as a gem, run under the current user and are really simple. A prepackaged mongoDB would do, too, but I cannot find such a thing. Is SQLlite my only option?
It sounds like you want DBM (which gives you access by id) and Ruby/odeum which gives you keyword search.
You may want to consider either a self-standing database like SQLite and Redis (no-SQL), or an ORM like DataMapper.
Since this doesn't touch a real problem of mine I'm somwhat uncertain, if it is even worth to be asked here. However maybe some of you would like to share your opinion on that.
In general I have to admit, that 'better' means anything and nothing at all at the same time. So I probably should be more specific, but I tried not to overflow the topic. In a regular hosted environment on one of those cheap webhosters (like Dreamhost), with around 1000 articles in Joomla, a couple of users and a few hundreds visitors a day, would a SQLite database with a persistent connection (sqlite_popen) perform noticeable faster than the MySQL equivalent (with the TCP/IP overhead etc.)?
Or in short: Would it be wise to call Joomla to support SQLite?
I have never used sqlite on a website, but I have used it extensively for other purposes and I quite like it. The truth is, you won't know till you try. If you try, I reccomend creating a db abstraction layer first so that you can easily swap in other db's.
The downside to sqlite is that it's not really meant to be a multi user database. If you rarely write to the db, but do lots of reading, sqlite will probably be fine. If you find that you need multiple processes writing to the same db, I believe sqlite uses file level locking to maintain database consistency.. So, if all you're tables are in the same file, you'll lock the whole file while it's being written to even if another process wants to modify a completely different table.
In my opinion it's not the big multi user databases of the world that should be worried about competition from sqlite... It's all the regular files out there (and there custom file formats) that applications create and use that should be shaking in their boots about sqlite...
Linux ISPs for whatever reason seem to have settled on MySQL. This is what they offer and you will lock yourself to a limited number of service providers if you wander outside the norm.