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
case, seeing it fail, then adding the code to handle it was rather satisfying.
I'm not jumping on the TDD bandwagon or anything, but libraries like Depot are
clear cases where vigorous unit testing is a big win.
- Revamped column type determination to use a mechanism that supports
delegation and does not rely on a heap of instanceof calls (which results in
runtime failure rather than compile time failure when a new column type is
added)
- Discovered that HSQLDB (at least) does not handle Byte, Short and Float
correctly. It returns them as Integer, Integer and Double respectively, which
then causes failure when trying to write those values back to the fields. We
work around this by converting non-null results to the correct type after we
get them back from the JDBC driver.
Ray Greenwell