Been very quiet for quite some time, so may as well provide a small update to
the handful of bots and webscrapers that visit this site. A project that I have
been working on for some time has been fully deployed, and I'm getting ever
closer to showing it off to a wider audience, once I've finished up an feature
or two. If you've been snooping around my GitHub account
or some of the repository's I have on there, then you may be able to find out
what it is. The next post I make here will be an introduction to this project.
Once I've shown this off to a wider audience I intend on writing some more
posts here too about the project itself, and some of the approaches I took to
building it.
Over these series of posts I have been exploring an approach that could be taken
when working with SQL relationships in Go. The precursor to all of this was the
initial ORMs and Query Building in Go. This explored one aspect of ORMs, the query building, but it didn't address
how relationships could also be handled in an idiomatic way. So before I wrap up
this series in this final post, let us address the code we have currently.
Previously, we
implemented some new interfaces, and utility functions to aid in the loading and
binding of the model relations. This was a much better improvement than what we
had before, however we still don't have a way of defining the relations
themselves in code. So far, we have heavily utilised callback functions to do
most of the lifting for us. For example, the model.Bind function we
implemented returns a callback that will gracefully handle binding the models we
load. In this post we will look at how we can utilise callbacks to set the
relations between models via code.
Last time, we refactored
our code, and implemented the loading of the relationships for the Post entity.
The implementation of this however was rather messy, as we did the equivalent
of sweeping everything under the rug. In this post however we will look at what
we've done, and see how this could be improved upon.
In the previous post
we setup the entity models for the blogging application, and built some custom
query options to handle the data we would be receiving via an HTTP request. Here
we will go about implementing pagination for our models, so we can support the
page query parameter, look into how we can refactor what we have in our
HTTP handlers, and start looking into loading entity relationships for models.
In my last post I
touched on the idea of using query builders for building up somewhat complex
SQL queries in Go. Well, in this post I'd like to go further, and explore how
this can be used to idiomatically build out a simple system for modelling
relationships in Go. This post going forward will assume that you have read the
aforementioned post.
Recently, I have been looking into various solutions for interacting with
databases with ease in Go. My go to library for database work in Go is
sqlx, this makes unmarshalling the data from
the database into structs a cinch. You write out your SQL query, tag your
structs using the db tag, and let sqlx
handle the rest. However, the main problem I have encountered, was with
idiomatic query building. This led me to investigate this problem, and jot down
some of my thoughts in this post.
I am an impatient man (if my sporadic typos, and last minute edits late at night
on my blog didn't make it obvious already). Recently this has started to stick
out to me much more, especially in regards to programming. More often than not I
would find myself just writing code haphazardly, then let the
compiler/interpreter point out the errors for me, some not so obvious, others
more obvious than I would have liked. This is a rather reckless approach to
take when it comes to development. I find that it prevents me from actually
thinking about what I am doing, and results in me producing tools and code that
are in unsatisfactory state.
It has been too long since my last post in which I
announced mgrt, the simple
SQL migration tool. Has much happened between then and now? Well, I showed off
mgrt to some people with little fanfare, and got around to implementing TLS
support for the tool. Right now it supports TLS for PostgreSQL, and to a certain
extent MySQL/MariaDB. And during my further developments of the tool itself I
have come to realise how much I truly despise working with MySQL. My feelings
for it are all superficial, so they hardly warrant a tangent.
As mentioned in my previous post, I have been working
on a tool for handling SQL migrations. Well, that tool is now ready to debug,
and is called mgrt. Much like
jrnl, I decided to take the Welsh
approach when it came to naming it.
It's been almost a month since my last
post, in which I detailed what
I hoped to achieve in regards to this blog, and to a slightly further extent
this year.
2019 is around the corner, and it has been 2 months since the
first post I made on this blog,
though I doubt anyone is actively following/reading. I have done very little to
advertise it so what should I expect? However I think now is an apt time to
justify the purpose of this blog, and layout some of the things I would like to
achieve in the coming year.
jrnl is a simple static site generator
written in Go. It takes posts written in Markdown, and converts them to HTML.
The generated HTML files are then copied to a remote destination, this can
either be a location on disk, or to a remote server. Unlike most other static
site generators jrnl does not serve the content that is generated. This post
shall serve as a brief introduction to jrnl, for more in depth usage refer to
the readme on the project's GitHub.