Brendan Graetz

  • PostgreSql is a relational database which adheres to ACID principles - atomicity, consistency, isolation, durability - and supports server-side joins between multiple entities (tables). Interestingly, in addition to this, it also supports a JSON data type natively, and provides a rich set of functions and operators to work with its jsonb type. 1 …

    continue reading »
  • What is an upsert, anyway?

    An upsert is short for “update or insert” in the context of SQL statements for databases.

    The typical use case for an upsert, is when you have some data that needs to be in a row, but you are not sure if that row already exists - based on its primary key - then you would need to either insert a new row, or update the existing row.

    However, upsert is not a command that was part of the SQL ‘99 standard, and therefore many database vendors either do not support it, …

    continue reading »
  • The Caffeinated Jester

    Having previously tested a NodeJs API server using mocha + chai + sinon, I have migrated a very large numbers of tests over to Jest recently. There were several hard-won lessons along the way, which requires one to change the way one approaches writing tests, and even thinking about tests.

    Jest is the new kid on the block, with other Javascript test frameworks being around for much longer. The value proposition of Jest is very strong though, and it is worth considering. …

    continue reading »
  • jest is a test runner that has all batteries included. Previously I have been using mocha, which is only a test runner. mocha, on the other hand, has assertions, mocking, and all the other bells and whistles, all baked in. With mocha, you would need to require() these in, from other modules - my go to ones were chai and sinon. Further to this, jest adds snapshot testing, which is something I have not previously done in mocha - that is perhaps something for a another article.

    Suffice to say that jest testing covers a huge surface area. …

    continue reading »
  • Many to many relationships are usually quite expensive in relational databases. For example, when you do a select in a purely relational database, you need to do two joins. When reading (select) from a database, joins are often the most expensive operation. Sure the cost of these can be mitigated through various optimisations, such as composite keys, indices on composite keys, SQL hints, et cetera; but are these really the only way? In a pure relational database system, that might be the extent of the surface area to be explored. …

    continue reading »

Copyright © 2008-present Brendan Graetz