ama-team / ruby-entity-mapper Goto Github PK

This would allow detailed control for specific attributes. If there is a hash of X, chances are that in case A hash keys would be used as entity IDs, and in case B as entity owner or something.

For example, chef resources have base set of instance variables and unknown set of resource-specific instance variables. Specific predefined type may be introduced, which, with the help of #14, would dump and set all nondeterministic instance variables.

It seems like implementation is _terribly_ slow - naive testing shows something like 200 ops/s on one (modern enough) core for relatively simple document. There should be some kind of performance control, including flamegraphs and benchmarks.

Naive testing shows that result depends heavily on load: for example, walking down 100-level hash could be done ~ 220k ops/s on the same machine, however, recursively iterating nested 5-level array (of 5 items in each, 3125 total) in single method (but using StopIteration rescue-block) could be done only 22 (!!!) times a second

Currently, mapper always reassembles entities as they come in, leaving no option for them to stay the same if they are already of target type. This should be controlled with a context and a type flag - completely disabling this is certainly not desired since immutable hash may be passed in as-is why there's request for hash, and, by so preventing end user from certain kind of operations.

There are quite common cases of pre-denormalization conversion:

• If input is String or Symbol, wrap it as { User: input }
• If input is nil, use empty hash instead
• If there's no :id field, take the Nth segment from the path
• Take everything in the input hash but fields user, options, and put it into options key:

user: git
identity_file: ~/.ssh/id_rsa
options:
  host: tiesto.com

->

user: git
options:
  identity_file: ~/.ssh/id_rsa
  host: tiesto.com

It's exaggerating to write them every time, so, probably, they should come as a bundled library

Attribute read and write allowance should be controlled via those attributes, and :sensitive should be deprecated

Attributes should have aliases option so they could be fetched from different input sources:

attribute :id, Symbol, aliases: %i[user_id login]

map({id: :bill}, User) == map({user_id: :bill}, User) == map({login: :bill}, User)

Current type system uses a dirty hack, treating parameter type as a regular type. This is perfectly legal in 0.1.0:

attribute :id, Symbol, :T, :Y, NilClass

resolved parameters just inflate type collection:

[Symbol, :T, :Y, NilClass].resolve(T: [Integer, String]) => [Symbol, Integer, String, :Y, NilClass]

This hole should be closed, so user would be able to assign either a list of types or single parameter to attribute. This should be done via introducing TypeCollection and Parameter mimicking TypeCollection instead of Type.

Currently this is valid

map('test', Integer') => 0

This is certainly what nobody wants

Currently attributes are fetched directly as instance variables and set the same way or via setter, if it exists. It is impossible to use implicit getters since nobody knows if that's getter or parameterful method, so this mechanism should be delegated to type declarators.

Currently each parameter may substitute only specific type:

Array<T> = Array<TrueClass> OR Array<FalseClass>

Instead, end user would need to substitute parameter with list of types:

Array<T> = Array<TrueClass | FalseClass>

Currently enumerator enumerates through all type attributes, even though some of them may not be set. In some cases it is needed to walk only over present attributes, otherwise default values in factory won't work

Currently, all operations are done recursively, and each entity level places several frames on stack. While it should be hard to cause stack overflow and there is essentially no way to implement this algorithm without saving current state, it would be better to place everything in heap rather on stack.

Currently, only fully-resolved types may be passed into mapper. Most probably most users would like it to substitute unresolved parameters with Any type or [Any, NilClass] automatically if proper flag is set.