import { build } from 'open-soql/modules/builder'; import { Account_norels, Contact_norels } from './types'; type Store = { Account: Account_norels[]; Contact: Contact_norels[]; }; const store: Store = { Account: [ { Id: 'Account/z1', Name: 'bbb/z1', Address: 'ccc/z1' }, { Id: 'Account/z2', Name: 'bbb/z2', Address: 'ccc/z2' }, { Id: 'Account/z3', Name: 'bbb/z3', Address: 'ccc/z3' }, { Id: 'Account

思った以上に制作に時間が掛かってしまいましたが、ようやく最初の安定版をリリースできました クエリ言語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のデータをクエリす

import { build } from 'open-soql/modules/builder'; import { staticJsonResolverBuilder, staticCsvResolverBuilder, passThroughResolverBuilder } from 'open-soql/modules/resolvers'; // See `src/types.ts` > `QueryBuilderInfo` const { compile, soql, insert, update, remove, touch, notifyRemoved, transaction, subscribe, unsubscribe, unsubscribeAllBySubscriber } = build({ functions: [{ // optional: For def

Salesforceのクエリ言語である「SOQL」をSalesforceとは関係なく実行するためのライブラリ「Open SOQL」を作りました。 github.com 作りかけになっていた自作のSOQL(typoではなくSalesforceのアレ)互換のクエリ実行ライブラリが、何とかクエリ実行可能になりました🎉 GraphQLのApollo Server勉強してるときに書き始めたので少し意識してます。DMLはまだできない😜https://t.co/GlJ8heN6XC— shellyln (@shellyl_n) July 13, 2020 GraphQLのApollo Serverにインスパイアされて、ユーザーがリゾルバを定義して任意のデータに対するクエリを処理できるようにしてみました。 こうして見ると、SOQLは文法こそSQLっぽいけれどやっていることはGraphQLとかに近いよう

はじめに 最近、kintoneを触っていて不満に思っていたのが、開発のパラダイムが前近代的になりがちであるということでした。 製品自体が小規模な部門内システム（これまでExcelファイルの共有やマクロで行っていたこと）をメインターゲットとしていると思われ、そもそも規模感のある開発を（敢えて？）想定しないためか、デプロイの管理機能を持っていません（サードパーティー製品で可能です）。 また、管理単位がアプリ（データベースの1テーブル）であり、複数アプリが連携するようなものを纏めて管理することができません（纏めて他の環境に新規作成するための「テンプレート」出力機能はありますが、アプリの更新には使えません）。 公式に配布されているCLIツール（customize-uploader、kintone-dts-gen）も単機能かつ単一アプリしか考慮しておらず、組織全体またはシステム全体の開発支援・デプロ

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert

先日kintoneで宣言的にフィールド値の検証を行うという記事を投稿しました。Tynderというライブラリを使い、型宣言を書くことで、（手続き的ではなく）宣言的に入力値の検証を行いました。 今回はその応用編として、日付や日付時刻型のフィールドを相対日付（例えば、今月、来月、今年、今年度）で検証します。 さらに、フィールドのエラーに合ったカスタムエラーメッセージを表示するようにします。 コード tynder.min.js lib.js (前回記事) app.js (下述) // アプリのレコード型を定義します // interfaceの各フィールドは、kintoneアプリのフィールドコードと一致させてください const definition = ` /** サブテーブル */ interface Table { itemName: string; itemValue: number; }

スキーマ検証ライブラリ Tynder v0.2.1 をリリースしました🎉 今回のリリースでは別のtype/interfaceのプロパティを型として参照できるようになりました🙂 (TypeScriptでは`a: Foo['x']`と… https://t.co/misBp0BkuJ

スキーマ検証ライブラリ「Tynder」v0.2.1 をリリースしました スキーマ検証ライブラリ Tynder v0.2.1 をリリースしました🎉 今回のリリースでは別のtype/interfaceのプロパティを型として参照できるようになりました🙂 (TypeScriptでは`a: Foo['x']`と記述するけど、こちらは`a: Foo.x`としました。TS出力では`a: Foo['x']`になります) pic.twitter.com/XKj0tRVkOa— shellyln (@shellyl_n) February 22, 2020

先日、TypeScript + Tynderから始める宣言的検証生活の記事にて スキーマ検証ライブラリTynderを紹介いたしました。 Tynderとは Tynderは、TypeScriptのサブセット＋独自の拡張文法から成るDSLによって 型の検査 単独の項目の必須・値の長さ・範囲や文字列パターンの検証 複数項目の相関や整合性検証の一部 (Union typeによる) を宣言的に行うことができます。 JSON Schemaを生成するオンラインツール 今回はTynderのスキーマ変換機能を使用して JSON Schema、GraphQL、Protobuf3 のスキーマを生成するオンラインツールを公開しました。 (GraphQL、Protobuf3については実験的機能です) TypeScript (Tynder DSL) → JSON Schema | GraphQL | Protobuf

github.com スキーマ検証ライブラリ「Tynder」最初の安定版となる v0.1.0 をリリースしました🎉 使い方についてQiitaに記事を書いています qiita.com また、ボイラープレートも用意しているのでぜひお試しください github.com ボイラープレートのバックエンド側は、何気にWebpack無しのES Modulesで書いています 追記(2/9) スキーマ変換のオンラインツールも公開しました。 qiita.com

Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? 皆さんは JSON Schema 使ってますか？ 現在では、Web APIのペイロード定義・検証、モックサーバー作成、ユーザー入力フォーム検証、設定ファイルのスキーマ定義・検証・IDEでのエラー表示など、多くの場面で、また多くの言語でライブラリが整備され利用されています。 JSON Schemaの強み Internet draftのフォーマットで仕様が公開されている 多くの言語での多くの実装（言語によっては複数）が存在する 1回書けば、フロントエンド、複数のバックエンドすべてで利用できる可能性が高い 代替実装が存在すると競争原理が働く

JavaScript / TypeScript でプログラムを書いていて、入力値や外部から受け取ったデータの検証って本当に面倒ですよね。 最近では、 JSON Schema を使うのが一般的かと思いますが、あのJSONを手書きするのは絶対に嫌。 ということで、型定義を(ほぼ)TypeScriptの記法で書けるスキーマ検証用のライブラリを作ってみました。 github.com パーサーは昨年自作したパーサーコンビネーター・フレームワークによって再帰降下法で作成しています。 github.com スキーマ定義は上述のほぼTypeScript DSLで記載できるほか、APIでも記述できます。 今年は脱 JSON Schema としたいです。