=============

MyBatisNodeJs is a port from the The MyBatis data mapper framework for Node.Js.

MyBatisNodeJs understands the same xml files as input like MyBatis Java.

MyBatisNodeJs assumes that your POJO's (domains objects) exist on the directory domain:

- Project
   domain (put your domain classes here)

* How to use:

1) Write your MyBatis mapping files:

To Know how to write mapping files read: 
http://mybatis.github.io/mybatis-3/

2) Create a connection to your database

```javascript
var mysql = require('mysql');
global.pool = mysql.createPool({
    host     : 'localhost',
    user     : '****',
    password : '****',
    database : 'database',
    typeCast : true,
    multipleStatements: true
});
```

3) To process the xml mapping files and get an sessionFactory instance:

```javascript
var mybatis = require('mybatisnodejs');

app.use(mybatis.Contexto.domainMiddleware);
app.use(mybatis.Contexto.middlewareOnError);

var sessionFactory  = new mybatis.Principal().processe(dir_xml);
global.sessionFactory = sessionFactory;
```

The string variable dir_xml points to the MyBatis mapping files directory.

The variable sessionFactory has methods for selectOne, selectMany, insert, update or delete objects.

4) Select one object:

```javascript
sessionFactory.selecioneUm('user.select', {id: 1}, pool, function(user) {
   //console.log(user);
});
```

The callback function is called with the user or null if not found.

Added support to Promises. The same old methods with Async suffix.

```javascript
var user = await sessionFactory.selecioneUmAsync('user.select', {id: 1}, pool);
```

Release Notes

Version 0.1.0 added support to prefix columns using table alias (from sql) 

Example:
The mapping

'''xml
  <select id="selecione" parameterType="map" resultMap="usuarioResultMap" prefix="true">
    select * from user
  </select>
'''

is same as:

'''xml
  <select id="selecione" parameterType="map" resultMap="userResultMap">
    select 
    u.id user_id,
    u.name user_name,
    u.login user_login
        from user
  </select>
'''
Hydration and memory
--------------------

`Principal.processe()` only parses the XML. Nothing is expanded at startup, so the
retained heap after startup is the size of the result map graph, a few MiB even for
hundreds of result maps.

Rows are turned into objects by a *hydration plan*. On the first row of a query,
`NoResultMap.obtenhaPlano()` looks at the columns the query actually returned, walks the
result map graph from the root concatenating `columnPrefix`, prunes every association or
collection whose prefix matches no column, and generates a specialized JavaScript
function for that shape (`src/Plano.js`). Each column is read once per row and each nested
object is resolved once per row; there are no closures, path arrays or string keys per
value. Plans are cached per result map and column set (at most 32 per result map, for
dynamic SQL that returns different columns). `plano.fonte` holds the generated source. The
generated code is split into functions of bounded size, because V8 does not optimize
functions above about 60 KB of bytecode and a wide projection (hundreds of columns) would
otherwise run in the interpreter, several times slower. On a real 601-column order projection
(81 nodes) that split took 2,000 rows from 81 ms to 25 ms on Node 14 and from 32 ms to 15 ms on
Node 20; the previous hydrator needs about 200 ms and 155 ms for the same rows. The code is
also emitted per row column, not per (node, column) pair: with unprefixed associations one
column feeds many nodes, and a 2,264-column, 6,144-node order plan went from 43 ms to 6.6 ms
per 100 mostly-NULL rows (the previous hydrator: 30 ms).

The semantics are those of the previous implementation, verified by the differential test:
every non-null value is assigned on every row where it appears, so a later row fills a
column that was NULL before; an object's key is the string concatenation of the truthy
values of its id columns (so 1 and "1" match, and composite keys concatenate without a
separator); nested objects are only created when that key exists, but an object the domain
constructor already created (for example a fiscal configuration or a kit component
configuration) keeps that instance and is filled even when its result map has no `<id>`;
collection items with the same result map and key are one shared instance within the
query, added once to each parent's collection even when several paths reach that parent; the
first time a query touches a collection of a parent, the property is replaced by a new array
(constructor defaults are discarded), which happens as soon as any column of its subtree is
non-null, even if the item has no key; the same result map can appear once per path (cycles
are cut); a discriminator picks the class per row; one-byte Buffers become booleans;
`columnPrefix` accumulates through the tree; a root without id columns merges all rows into
one object. The generated code processes columns in row order and creates each nested object at the
first non-null column of its path, so the discriminator is read at that moment, when two
paths reach the same instance the last column wins, and constructors, setters and object keys
run in the same order as before.
Duplicate column warnings are emitted when a plan is compiled, if `global.exibirWarnings` is
set.

Run regression tests with `npm test`. It includes a differential test that feeds the same
rows to the previous hydration (commit d645e33, extracted from git into
`tests/support/antigo`) and to the current one and compares the objects. Benchmarks need
no database:

```sh
npm run benchmark:memory
npm run benchmark:memory -- /absolute/path/to/mappings [depth]
npm run benchmark:concurrency
npm run benchmark:concurrency -- tests/support/antigo/No.js   # previous implementation
```

Measured on 2026-09-17 with the built-in fixtures (medians of five rounds, 64 interleaved
queries of 2,000 rows each, four nesting levels):

| Metric | Node 26.8.2 previous | Node 26.8.2 plans | Node 14.21.3 previous | Node 14.21.3 plans |
| --- | ---: | ---: | ---: | ---: |
| Time per round | 224 ms | 38 ms | 494 ms | 70 ms |
| Rows per second | 572k | 3.3M | 259k | 1.8M |
| GC events per round | 16 | 5 | 31 | 9 |
| Sampled peak heap | 123 MiB | 52 MiB | 108 MiB | 50 MiB |
| Startup retained heap, 12 chained maps | 34.1 MiB | 0.1 MiB | | |

Startup memory with real mappings depends on the graph: run the memory benchmark against
the application's XML directory to measure it.