sure what this is really testing. If the CRUD test with CustomType works, then
transforming field marshallers work, so why do we need to make sure they have a
specific class name?
the build, but other errors in class processing seem to lead to skipping, so I'm not rocking the
boat.
If @GeneratedValue is on a field without an @Id, depot creates the necessary indices to generate the
value, but it doesn't actually do the generation on insertion. Rather than making it work without a
good use case for it, I'm adding this check to keep people from stumbling into a broken design.
One test no longer works, because the StringArray transformer now inherits
the fromPersistent method from StringBase, and has a generic return type.
Perhaps we can update FieldMarshaller to deal with Types instead of classes
when validating... But for now I did what all bad programmers do when a test
fails: comment it out.
Transformer is now an abstract class with a default init() method.
The Type parameter has been removed from fromPersistent().
The Transformer annotation now has some new attributes that
can be used to hint whether you want a result that is immutable or interned,
the meaning and support of both is completely up to the Transformer.
Brought back my uber Iterable<String> transformers, with immutable/intern
support in a single Transformer.
- interning will intern the strings
- immutable will wrap the collections in Collections.unmodifiable*
(using a guava Immutable collection ends up creating a temporary
builder collection and then copying the elements)
- if immutable AND interning then the collection itself is
"interned".
At some point I'll add support for nearly any Iterable
of an otherwise supported type, so that our Records can have
List<Integer> and other such fields.
interned Strings, or both.
I may rework this into attributes that can be specified for any
@Transformer annotation, and leave it up to each Transformer
whether they are honored (and how).
to FindAllQuery.
- We don't need to destructively modify the Set of keys to fetch if we hold
on to one iterator.
- We can create an ArrayList that won't need to grow if our keys Iterable
happens to be a Collection.
- And, just generally prefer Lists factories to specific constructors.
columns in the results to match the FieldMarshaller column names, so we have
to use those rather than the field names. Also, shadowed fields need to use
the column names of the fields that they're shadowing.
date from date(). We should probably just modify DateFuncs.date to
return a date in both cases (perhaps with a separate DateFun.DateCast
class), but for now it's easier to have MySQL return a timestamp as
well.
the terminator (we encode the terminator as a different character).
This is somewhat nicer when inspecting an encoded String, and allows
for a future in which the decoder easily counts the number of terminator
characters and pre-allocates the storage, if we so desired.
There are some optimizations that could probably be made, but
for now I defer to the new One Rule of Optimization:
"Do not optimize for performance unless it does not weird the code or
it Really Matters".
- continue to terminate Strings with a newline
- turn newlines inside a String into "\n"
- turn null elements into "\0".
This is one additional character when encoding nulls, but
I think it may improve readability..
contains generic type information which would allow a transformer to do the
right thing with a field of, say, type Set<Integer>.
If we had unit tests for StringIterable, I'd know that I didn't just break it.
I'd also know that it worked in the first place. :)
to the ternary operator are boolean constants, don't use the ternary operator.
a ? true : x == a || x
a ? x : true == !a || x
a ? false : x == !a && x
a ? x : false == a && x
Michael Bayne