Digging further into #3857.
See also #8955, #8956.
As [previously
discussed](https://github.com/typeorm/typeorm/issues/3857#issuecomment-699505893),
the query builder currently suffers from poor performance in two ways:
quadratic numbers of operations with respect to total table/column
counts, and poor constant factor performance (regexps can be expensive
to build/run!)
The constant-factor performance is the more tractable problem: no longer
quadratically looping would be a chunky rewrite of the query builder,
but we can locally refactor to be a bunch cheaper in terms of regexp
operations.
This change cuts the benchmark time here in ~half (yay!).
We achieve this by simplifying the overall replacement regexp (we don't
need our column names in there, since we already have a plain object
where they're the keys to match against) so compilation of that is much
cheaper, plus skipping the need to `escapeRegExp` every column as a
result.
`TableForeignKeyOptions.name` reflects the name of the foreign key. The name of the table where this foreign key resides is actually referenced by `referencedTableName`
Context: the query builder is pretty CPU intensive, and can be slow -
e.g. https://github.com/typeorm/typeorm/issues/3857
One of the things which makes this slow is `escapeRegExp` in the query
builder: we freshly construct the same RegExp once per
`replacePropertyName` invocation (many times per overall query!) and
since the RegExp itself is constant -- we can lift it out and construct
it once.
Over-all this saves about 8% on our query build times as measured by
#8955.
Motivation: the query builder (and within it, replacePropertyNames and
associated functions) is pretty CPU intensive. For our workload, it's
one of the hottest functions in our entire stack.
While improved in https://github.com/typeorm/typeorm/pull/4760,
There are still outstanding issues relating to perf e.g. https://github.com/typeorm/typeorm/issues/3857
As we all know though, the first step in optimization is to measure
systematically ;)
https://wiki.c2.com/?ProfileBeforeOptimizing
On my machine, this benchmark runs in ~3500ms or about 0.35ms/query.
This tells us there's a way to go - on my stack, that's about 1/3 of a
typical query's latency!
* feat: add constraintName to JoinColumn
Add a constraintName to JoinColumn decorators to allow specifying foreignKey name.
Use constraintName when building JoinTable entities as well.
Partially solves: #1355
* test: add tests for constraintNames on JoinColumn
* docs: add constraintName documentation to JoinColumn and JoinTable
* test: update snapshot in 5444 test
Add constraintName property with correct variable undefined to snapshot in tests for issue 5444.
* prettier
* added support for custom FK name in Sqlite;
added test;
* removed .only
* fixed FK constraint renaming on table/column rename
* minor fix
* fixed @Unique and @Index constraints renaming on table/column rename
* working on constraint name support for PK
* replaced `constraintName` with `primaryKeyConstraintName` and `foreignKeyConstraintName`
* fixed failing test
* working on constraint name support for PK
* updated docs
Co-authored-by: Matthijs Hatzmann <matthijs.hatzmann@tradecast.eu>
* added integration with typeorm metadata table for mysql generated columns
* added more tests
* fixed failing tests
* added test case and fix for #8761
* fixed failing tests
* fixed failing tests
* fixing failing tests
* working on postgres implementation
* added test for postgres;
fixes in postgres generated columns;
* working on "gc" implementation in cockroachdb
* added "gc" implementation for sql server
* added "gc" implementation for oracle
* removed unneeded files
* added "gc" implementation for sqlite;
added additional test cases;
* fixed failing test
* fixed failing test
* minor fix in cockroachdb
* added "gc" implementation for spanner
* minor change
* test: test usage of generics with Repository class
* test: cleanup
* fix: update DeepPartial to work with generic Repository
* fix: restore package-lock.json from typeorm/master
When using a STI scheme and an EntityManager or Repository
with base class target, the wrong discriminator was written to the
database despite giving an concrete entity.
This was because of the entity's target being ignored in favor of the
target of the Repository or the EntityManager.
fixes#2927
The HSTORE type is the only type bypassing the transformer
column options.
This fix makes the option available to this column type as well.
Co-authored-by: Samuel Roy <sam@pricemetry.com>
Changed to nodejs workaround instead of relying on shebang parameters, as they work a bit differently on some linux distros, and using the "-S" parameter breaks the CLI on Windows
Closes#8818
