overschakelen van MySQL naar PostgreSQL voor Ruby on Rails omwille van Heroku

Veelvoorkomende problemen:

1. GROUP BY-gedrag. PostgreSQL heeft een vrij strikte GROUP BY. Als u een GROUP BY-clausule gebruikt, moet elke kolom in uw SELECT ofwel in uw GROUP BY voorkomen of in een aggregatiefunctie worden gebruikt.
2. Gegevens inkorten. MySQL zal stilletjes een lange string afkappen om in een char(n) te passen kolom tenzij uw server in de strikte modus staat, zal PostgreSQL klagen en u uw string zelf laten inkorten.
3. Citaten is anders, MySQL gebruikt backticks voor het aanhalen van identifiers, terwijl PostgreSQL dubbele aanhalingstekens gebruikt.
4. LIKE is niet hoofdlettergevoelig in MySQL, maar niet in PostgreSQL. Dit leidt ertoe dat veel MySQL-gebruikers LIKE gebruiken als een hoofdletterongevoelige operator voor tekenreeksgelijkheid.

(1) is een probleem als je de group van AR gebruikt methode in een van uw query's of GROUP BY in een onbewerkte SQL. Zoek eens naar column "X" must appear in the GROUP BY clause or be used in an aggregate function en je zult enkele voorbeelden en veelvoorkomende oplossingen zien.

(2) is een probleem als u stringkolommen overal in uw toepassing gebruikt en uw modellen de lengte van alle niet correct valideren inkomende tekenreekswaarden. Merk op dat het creëren van een stringkolom in Rails zonder een limiet op te geven in feite een varchar(255) creëert kolom dus er is eigenlijk een impliciete :limit => 255 ook al heb je er geen gespecificeerd. Een alternatief is om t.text . te gebruiken voor uw strings in plaats van t.string; hierdoor kun je zonder boete met willekeurig grote strings werken (tenminste voor PostgreSQL). Zoals Erwin hieronder opmerkt (en elke andere kans die hij krijgt), varchar(n) is een beetje een anachronisme in de PostgreSQL-wereld.

(3) zou geen probleem moeten zijn, tenzij je onbewerkte SQL in je code hebt.

(4) zal een probleem zijn als u LIKE ergens in uw toepassing gebruikt. Je kunt dit oplossen door a like b . te veranderen naar lower(a) like lower(b) (of upper(a) like upper(b) als je wilt schreeuwen) of a ilike b maar houd er rekening mee dat ILIKE van PostgreSQL is niet standaard.

Er zijn andere verschillen die problemen kunnen veroorzaken, maar dit lijken de meest voorkomende problemen.

Je moet een paar dingen doornemen om je veilig te voelen:

• group oproepen.
• Raw SQL (inclusief eventuele fragmenten in where oproepen).
• Bevestiging van tekenreekslengte in uw modellen.
• Alle gebruik van LIKE.