I am thinking of working on a Rails application that uses PostgreSQL. I have some questions before I am comfortable using Rails:
Is PostgreSQL support in Rails less superior than, say, MySQL.
Would it feel any different if using PostgreSQL?
Are there any cases where using PostgreSQL fail to work?
Thanks.
After having used sqlite, mysql and postgresql with Rails, I prefer using postrgresql.
Installation for OSX, Ubuntu and Windows went well as opposed to buggy installs for other DBs.
I had to install the following gem to use postgresql:
install gem postgres-pr
It may "feel" different when you come across complex databse requests where you add in special conditions such as extracting the month from a date as the actual text will differ depending on the database system. Also, postgresql delimits strings in request with E'' so sometimes a request using a text-field may come up with an error if you're not careful with your :conditions => [].
PostgreSQL support with rails is excellent - I would not hesitate to use it.
If you are looking for examples, Planet Argon is a high-profile web development house that primarily does Rails with PostgreSQL in the background. You can read more about their work at Robby Russel's blog.
Heroku uses PostgreSQL exclusively for their Ruby web hosting - including lots of Rails deploys, of course.
At my employers we use PostgreSQL exclusively, for a large Rails application. We use complex queries etc and so far had no problem with Rails & Postgres itself.
However, if you rely a lot on 3rd party plugins that work on top or beside ActiveRecord, you might want to check their support for Postgres. E.g we ran into inconsistencies using the searchlogic plugin.
Postgres support is very good, albeit support for writing plpgsql functions, triggers and composite primary keys inside migrations leaves much to be desired.
Related
Our main project has been using a now-very-old Flyway version since inception. (v3.2.1)
Flyway has made loads of improvements over the years, and v6+ appears to contain many interesting features for our MySQL schema.
Attempting the supported upgrade path, I ran into a few problems--e.g. our .sql migrations refuse to migrate from start to finish; Flyway v3.2.1 considers all our SQL migration valid, but v4+ chokes on some odd comment syntax. Naturally, file fixups to get migrate working will produce different check sums, which is an obstacle to safe upgrade. I'm well aware of the schema table name change in v5; that's not insurmountable.
I'm also eyeing Liquibase vs. and online schema migration tools; FB, Percona and GitHub's OST (gh-ost) look interesting, but we use foreign keys, and we'd need more replicas, so that may not be in the cards for us right now.
For now, I'm interested in a new baseline w/ Flyway v7 beta or switching tools. If you deploy SaaS on k8s and have any generic advice--I'll take it, but I'm specifically interested in one thing:
How have folks overcome the issue where newer versions of Flyway no longer accept existing SQL migrations. Or, has anyone "given up" and just created a new baseline, rather than doing the long upgrade path? (or, switched from Flyway to another tool with similar merits)
There are at least two problems here, with many moving parts:
Dealing with the tooling's constraints, and how to deal with Flyway 3->7+ (follow the tool's doc)
How to incorporate large prod SQL migrations in general, which is too general a problem to cover here.
If anyone has better (less general) advice on the first, I'd love to hear it.
Re: the second, we're looking to our infra and deployment from off-the-shelf tools.
Most projects I've worked on have been Spring based. (large ecosystem, even without the k8s bits)
You may give a shot to bytebase (bytebase.com).
Web-Based
Open-Source
Can do MySQL schema migration triggered by GitHub/GitLab with full history
I know it may be reinventing the wheel to some extent, but I'm creating a package of my own in Node.JS where I would like to keep dependencies to an absolute minimum. This program should connect to SQL (at first, just MySQL, but eventually several different flavors, so if the same answer applies to PostgreSQL, MSSQL, etc. a note about that would be much appreciated) and be able to run queries and such. Is there a way to do so through Node without using an external package like mysql or mssql?
I do understand that this sounds very impractical, and so I see the need to use "fully debugged open-source software" as the commenter put it. However, requiring a new package for every SQL flavor I extend my program to would be impractical as well. If I must install a package, is there some sort of universal one that I can use for Node.JS (something like PDO in PHP)? If so, what is the basic way of connecting to, say, MySQL?
Thanks in advance.
Node has RDBMS-specific packages like mysql, pg, sqlite3, mssql, ibm_db, oracledb, ... all the same except where they aren't.
The php world boasts a couple of database abstraction layers that can talk to multiple makes and models of RDBMS. For Java, JDBC serves the same purpose.
The npm ladc package is a similar project for nodejs; it uses the existing packages for connecting to databases. It seems to be in an early version and not heavily used, according to its npm page.
Sequelize is an object-relational database abstraction above some RDBMSs. If you are able to use an object-relational model for your data, it's probably a good choice. If you're using lots of pure SQL, ladc might make sense.
It seems as if you're blazing a trail with your project.
I am going to be writing to a MySQLite database file, using Perl's DBD:SQLite module, and I wondering if it is possible for this file to be read by any distribution of MySQL? Is there a better way to create a simple MySQL database (using Perl)?
If it means anything, I'm only going to be using the database to store key-value pairs based on unique ID numbers for the keys. I tried BerkeleyDB but there is little support for it on Perl and I could not get it to work correctly in the past on certain versions of Windows.
Edit: I am aware that BerkeleyDB is a better way to do this, but when I was writing scripts for it, most of the methods have TODO, and I've had mysterious bugs on Windows Server 2003 using the same airtight code that ran for 2 weeks straight on my Win7 machine at home.
MySQL and SQLite are completely separate RDBMS systems. There is no such thing as MySQLite. To the best of my knowledge, MySQL cannot read SQLite databases.
If all you really want is a key-value store, perhaps look at Redis: http://code.google.com/p/redis/
I use Perl's DBI module which I can use to read databases using either MySQL or SQLite. All you need is the correct driver. In fact, if you write your program correctly, the backend database (either SQLite or MySql) is irrelevant. Your program will work with either one.
However, you can't use a SQLite database and then treat it as a MySQL database. They're two different creatures. Your program can be database agnostic, but once you chose a database, you can't switch back and forth. It'd be like opening an Oracle database as a MySQL database.
See This posting on Perl Monks for more info.
BerkeleyDB is well supported by perl. You have a choice between the older DB_File and the more fully featured BerkeleyDB module.
But there are tons of choices. If you don't want to have to run a separate server process, use DBI and DBD::SQLite or BerkeleyDB or any of the AnyDBM_File modules. For a simple server-based key-value store, there's redis or the older memcached.
I am planning to use Locomotive for a project...But as the official website says it cannot work with MySQL. However my requirement is to use it with MySQL.
Has any one used it with mySQL? Any pointers or advises would be great. Thanks.
Cheers,
Abi
Locomotive uses Mongoid - which is an ORM for MongoDB. As such, you cannot use it with MySQL at all, since it leverages some features (dynamic attributes), which traditional RDBMS databases (such as MySQL) do not support.
That being said, MongoDB is pretty easy to install, so if you can get around your requirement of MySQL, then you should have no problems.
Decoupling Locomotive from MongoDB would be no small task at the moment, which is not to say that it is impossible.
Regarding your requirement of MySQL, if you are working on incorporating Locomotive into a larger web-application, one thing to consider is that your non-Locomotive models can still live in MySQL regardless of where Locomotive keeps its data.
From what i know it wont be possible to use locomotive only with mysql as it use heavily mondodb.
However it's not a problem to build your app living together with locomotive and use what ever orm you like.
Just configure your database.yml and the magic will happend ;)
cheers,
Gregory horion
I'm starting a new opensource project (for real estate) and wanted to focus on using MySQL, but would also like to ensure it works in PostgreSQL. What is the best way to doing this without having to continually test in both environments? I'm assuming the db schema is close to the same, but there could be some differences on the SQL script to set up the databases - right? what about scripts?
What Development environment are you using?
if your using .NET, JAVA you could use an ORM(Object Relational Mapper) like Hibernate (NHibernate for .net) and that will take care of you db interoperability, for PHP or ruby I would look for something equivalent.
Edit point:
After looking at your profile it looks like your a python developer so you may find this link helpful what are some good python orm solutions posed on SOF 10 months ago
Seems to me that the only way to make absolutely sure is to target them both in your testing. I'm sure both DB's have development paths that may diverge, and you'll often find yourself faced with the prospect of using some MySQL-specific feature.
It's a PITA but the longer you go between tests against both the better the chance you'll have fireworks when you do.