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.
your POM at nextversion-SNAPSHOT and then when you do all the release
machinations, it shaves the -SNAPSHOT off, tags, builds and ships your thing,
then commits a new POM with nextnextversion-SNAPSHOT as the version.
Why does the Java dependency management world have to suck so badly? Is it not
crazy to want projects to be able to publish their own releases and to make it
easy for other projects to depend on those published releases? Why do I have to
reconfigure the standard configuration to add new repository sources? Why
doesn't the IvyRep resolver work and do something sophisticated?
Why can't I just fucking put in my ivy.xml:
<dependency org="com.samskivert" name="samskivert" rev="1.0" conf="runtime"
source="http://samskivert.googlecode.com/svn/releases"/>
and have Ivy do something smart like assume that there will be a standard
directory structure at the specified root and that it will contain the ivy.xml
and module.jar file that it needs, and just download them?
Instead I have to write a ton of fucking boilerplate and wire it all in via a
separate ivysettings.xml file, and then helpfully instruct anyone who uses my
fucking library that they too can have the pleasure of doing the same.
Michael Bayne