Marvel Fusion's diode-pumped laser systems with ultrashort pulses

Marvel Fusion's diode-pumped laser system with ultrashort pulses dramatically reduces costs and can drastically reduce the need for magnetic confinement.

Short Queries

  • By Artem V. Shamsutdinov
  • June 17th, 2022

One thing I'm starting to think about is AIRport adoption. It will certainly be useful for building production applications but it's query syntax lacks a bit when it comes to quickly cranking out prototypes. Or rather, it really doesn't take that much time to define an entity query with a join but the perception I get when I type them out is that it's tedious.

The "feels slow" part.

There are two parts to the existing queries that will probably bother developers who just want to throw together a quick join. Here is an example of a standard AIRport (entity) query:

import { QEntityA, QEntityB, QEntityC, QEntityD, Q} from '../generated/generated';

class ADao {

	sync findSomething(
		field1Value: string,
		bUuId: string,
		dUuId: string,
	) {
		let a: QEntityA,
		    b: QEntityB,
		    c: QEntityC,
		    d: QEntityD
		return await this._find({
			select: {
				'*': Y,
				entityB: {
					entityC: {}
				}
			},
			from: [
				a = Q.EntityA,
				b = a.entityB.leftJoin(),
				c = b.entityC.leftJoin(),
				d = a.entityD.leftJoin()
			],
			where: and(
				a.field1.equals(field1Value),
				b.equals(bUuId),
				d.equals(dUuId)
			)
		})
	}

}

First it's the "let" at the top of the method. These declarations are a language requirement to get the query working. They aren't really part of the underlying SQL and that's annoying in itself. When you are trying to quickly write a select statement having to go back to the top and add an alias for every entity in the SELECT and the WHERE clauses is rather annoying. On top of that you also have to be aware of the Q prefix for all Query Entities and have to import them.

The second annoying part is the FROM clause. For vast majority of the cases you'll just be doing LEFT JOINs. And wouldn't it be great if the FROM clause was just implied and aliases worked by convention?

The new "Quick and Dirty"

To improve the perceived convenience of the Query API I'm proposing a secondary, much more limited API that is quick to type out:

class ADao {

    async findSomething(
		field1Value,
		bUuId,
		dUuId
	) {
		const a = this._select({
			'*': Y,
			entityB: {
				entityC: {}
			}
		})
		return await this._where(
			and(
				a.field1.equals(field1Value),
				a.entityB.equals(bUuId),
				a.entityD.equals(dUuId)
			)
		)
	}

}

It's much shorter, has no forced imports or variable declarations (except the SELECT clause variable). All of the entities in the SELECT and the WHERE clause are automatically joined with LEFT JOINs. No fluff whatsoever.

When

Since this syntax isn't required for a fully functioning framework (and since it will take work to implement the necessary query wrappers and the ability to deduce what joins to build) I'm not planning on implementing it until Beta is out. It's really all about when will it be most needed by the community - when AIRport will be used to quickly crank out functional prototypes.