はじめに 私は現在、Salesforceで使われているSOQLというクエリ言語のオープンソースとしての再実装に取り組んでいます。 以前はTypeScriptで実装を行いましたが、直近ではGoによりパーサーを書き直し、実行エンジンの再作成をしています。 Goによるクエリパーサーが主要なクエリへの対応を完了したので、クエリをER図として可視化するツールを作ってみました。 ツールで使用したもの フロントエンドはVanilla JavaScriptで作っています。 ER図のレンダリングにはMermaidを使用しました。本当はPlantUMLの方が好きなのですが、クライアントだけで何とかしたいのでMermaidを選びました。 SOQLのパーサーははじめに記載した通り、自作のものを使用しています。 パーサーはパーサーコンビネーターとして構築されており、パーサーライブラリも自作のものを使用しています。

本ドキュメントでは、Go言語向けのパーサー・コンビネーター・ライブラリ「takenoco」について解説します。 パーサー・コンビネーターとは、小さなパーサー(構文解析器)の関数を組み合わせて目的のパーサーを構築する、パーサーの構成方法です。 プログラミング言語の「高階関数」という仕組みによって比較的容易に実現することができます。 takenoco は、文字列、または、任意の型のスライスをパースし、AST (abstract syntax tree; 抽象構文木) に変換するための基盤と、汎用的な小さなパーサー群、生成規則によるASTの変換機能を提供します。 takenoco のパッケージ takenoco は以下のパッケージによって構成されます。 base/: 型、パーサー基盤および、文字列/任意の型のスライス 共通の汎用的なパーサー群を提供します。 string/: 文字列の汎用的なパー

はじめに Goの自作パーサーコンビネーターライブラリ「takenoco」を使って、トイ言語を作ったり、まだ公開していないプロジェクトでパーサーを作ったりしているのですが、自分も活用できる実用的なサンプルを作ろうと思い、JSON・TOMLパーサーの作成を思いつきました。 完成したのがこちら「go-loose-json-parser」です。 ※作り始めたとき、JSONパーサーだけのサンプルにしようかと思っていたので、リポジトリ名にはTOMLが入っていません😖 Live demoはこちら ※wasmで動いています Goには既に有名なTOMLパーサー(1),(2)もあるので、作成する必然性は無いのですが、車輪の再発明は楽しいですね。また、プロジェクトの依存関係が自家製なのは精神衛生上、大変良いです。 コンセプト まず、最初に作り始めたJSONパーサーについて、パーサーライブラリの特性も考え、ゴリ

github.com Unmarshallerを実装し、型付きの変数にマップできるようになりました Loose JSON | TOML normalizer でvalidではないJSON・TOMLからvalidなJSONへの変換を試せます

github.com

前回、 Go の学習を始めた際のまとめを記事として書きましたが、Makefileの作成は後回しにしていました。 Go のプロジェクトでは殆どの場合、 Makefile によりビルドを記述しています。Makefileは GNU Make 用のルールを記述したファイルで、 マルチプラットフォーム で利用することができます。 Makefile 完成版 今回、 Go 用のマルチプラットフォーム (Windows-cmd.exe, Windows-PowerShell, Windows-Git-Bash, Linux(ChromeOS-Crostini(Debian), WSL(Ubuntu), 他)) で動作する Makefile を作ってみました (GNU Make は Chocolatey の非 MinGW 版 4.3 を使用しました)。 Docker の scratch イメージで動作するよ

最近、 Go の学習を始めました。入門書や 公式のチュートリアル を終えてもなかなか解らないことをまとめてみました。 1. パッケージ作成・パッケージ管理 1. a. ディレクトリ構成は非公式ながら標準と目されるものがある(らしい) Standard Go Project Layout /cmd にmainのアプリケーションのソースを置きます。 /pkg にライブラリのソースを置きます。 /src にソースを置いてはいけません。 なお、このディレクトリ構成は go コマンド(go build 等)がデフォルトで認識するディレクトリ (/src , /pkg , /bin) とは全く異なるので注意が必要です。 2021-05-24 追記 このレイアウトは殆ど普及していないとのこと。また、リポジトリ名が「標準」を名乗るのは誤解を招くとのissueも挙がっています。 個人的な意見として、ライブラ

export interface Account_norels { Id: string; Name: string | null; Address: string | null; } export interface Account extends Account_norels { Contacts: Contact[] | null; } export interface Contact_norels { Id: string; Foo: string | null; AccountId: string | null; } export interface Contact extends Contact_norels { Account: Account; } import { build } from 'open-soql/modules/builder'; import { Acc

思った以上に制作に時間が掛かってしまいましたが、ようやく最初の安定版をリリースできました クエリ言語SOQLのオープンソース実装「Open SOQL」最初の安定版となる v0.1.0 をリリースしました🎉 Apollo Serverのようにリゾルバを定義することで、任意のデータにSQLライクなクエリ・インターフェイスを提供できますhttps://t.co/GlJ8heN6XC— shellyln (@shellyl_n) August 17, 2020 qiita.com 今後、まずはネストした関数呼び出しの実装を行う予定です。

本日(2020-08-17)、Open SOQL 最初の安定版となる v0.1.0 をリリースしました🎉 Open SOQLはSalesforceで使われている独自のクエリ言語「SOQL」(Salesforce Object Query Language) のオープンソース実装版です。 オリジナルのSOQLは長い歴史を持ちますが (詳しい歴史を辿れないのですが、2008年には既に存在していたようです)、オブジェクトのグラフを利用者が必要な項目に絞って取得できる (つまり、オーバークエリしない) という、まるでGraphQLのような特徴を持っています。 (GraphQLの初版は2015年のようです) 文法もSQLに近く学習コストが抑えられており、さらにGroup byによる集計もサポートしています。 Open SOQLはオリジナルのSOQLとは異なり、Salesforceのデータをクエリす