2fd131c0d2
Any collection of anything that extends QueryClause is generally all we need.
2008-09-03 00:55:07 +00:00
beef018b03
Nixed unused import.
2008-08-25 18:16:35 +00:00
43e1a38703
Let's go all the way up to Short.MAX_VALUE.
2008-08-25 16:27:43 +00:00
d54c633401
Don't try to use an IN() clause with more than 16738 entries.
2008-08-25 15:57:43 +00:00
01962836f7
Nixed unneeded log message.
2008-08-20 18:17:52 +00:00
8dec5386f2
Don't require a schema version for computed records.
2008-08-20 01:28:31 +00:00
a670beb665
A couple of changes:
...
1. Schema version is now always required. The "support" for unversioned schemas
was half-baked anyway.
2. Migration and table creation is now done in such a way that multiple
processes can start up and won't step on one another as they all try to migrate
the same schemas. Instead one will get a lock and do the migration and the
others will patiently wait.
2008-08-20 00:35:12 +00:00
64d186d08b
Report a better error message if a bogus rename is attempted. Some formatting
...
cleanup.
2008-08-20 00:22:41 +00:00
22fb614f34
Unfiddle long lines.
2008-08-16 20:30:52 +00:00
338bb62d9f
PreparedStatement.setObject() does a lot of runtime type checking, so we don't have to do setShort(), setString(), etc. But we do have to convert ByteEnum's to their byte representation.
2008-08-07 06:02:41 +00:00
86f3b1e293
The PostgreSQL datatypes for float and double are REAL and DOUBLE PRECISION.
2008-08-07 05:45:25 +00:00
a48c93be4a
From Dave: a bunch of @Override annotating and some other cleanup.
2008-08-06 12:59:06 +00:00
a0731b34c1
Trimmed trailing whitespace.
2008-08-04 12:37:23 +00:00
f07694895e
Fixed some bogus null checks and assignments.
2008-08-04 00:49:37 +00:00
8f2cf98c17
Le metric crapload of generics cleanup.
2008-07-30 13:53:24 +00:00
4e002054e4
Unused import pruning.
2008-07-26 20:14:38 +00:00
e3adfea99e
Handle SEQUENCE strategies, which are not yet implemented. This'll fix David Hoover's super-strict compilation urges, besides being a generally good idea.
2008-07-21 19:36:47 +00:00
eac0e214ef
Always do a (potentially distributed) cache remove on invalidation, regardless of what's in the local cache. From Kyle Sampson.
2008-07-17 12:16:39 +00:00
8f1b3ad8b0
2008-07-15 00:03:10 +00:00
33e159047d
Use new logging shim.
2008-05-27 18:40:39 +00:00
c16003177d
2008-05-19 18:32:58 +00:00
7e93da6fc0
2008-05-16 03:20:27 +00:00
195fabe2cc
We need parens so that operators are evaluated in the right order.
...
This adds extra params around a bunch of things. I'll let the gods of Depot
sort that out.
BTW: Arithmetic.Div is still totally broken. It somehow booches the prepared
statement. I tried changing the operator String to "//" and that sorta worked,
but then the next operator over was missing...
I'm working around this using Mul, but it'd be nice..
2008-05-16 02:10:07 +00:00
31b886aed2
2008-04-25 18:32:44 +00:00
4eb7d9ecd3
Pass -Dcom.samskivert.jdbc.depot.debug=true to have Depot log queries before
...
they are executed.
2008-04-23 23:29:07 +00:00
513ce9aa60
Yank our nomenclature into consistency -- indices, not indexes; fields(), not fieldNames(), as per Ray's suggestion.
2008-04-14 20:18:45 +00:00
13121249cb
The query is in no way guaranteed to uniquely keyed rows, so let's stuff the result into a Set. We should probably add the 'unique' modifier to the actual query, but that requires a bit more cross-dialect-and-version research than I'm willing to give it just now.
2008-04-06 14:57:14 +00:00
6e532a2b37
Update comments.
2008-04-01 21:40:11 +00:00
3f26158031
Nix @Table, move its fields into @Entity.
2008-04-01 21:27:20 +00:00
1b5ca78946
Throw a useful error message when we are asked to create a primary key with
...
mixed null and non-null values.
2008-03-29 23:19:42 +00:00
609e1aff0c
Support update partial with a Key<T>.
2008-03-29 00:32:19 +00:00
7056f6c05c
Don't try to build an UPDATE statement at all if no key were set on the record sent into store(). Also throw a sensible (if scaredy-cat) exception rather than an NPE if no WHERE clause were given to an UPDATE. We probably do want to allow rampant nutty 20,000-row UPDATEs at some point, but not because of an accidental null key.
2008-03-10 22:28:11 +00:00
2783d31ca2
We need to guard against simultaneous calls to getCache().
2008-02-14 18:55:21 +00:00
ff165e68a4
Added NotEquals.
2008-02-12 21:52:44 +00:00
da0841c095
None of these constructors actually throw a PersistenceException, so we'll go
...
ahead and not declare that they do.
2008-02-07 19:59:54 +00:00
4495e56e52
Another type clarification.
2007-12-17 19:46:28 +00:00
951b201064
Support taking a List as well as a varargs array. There are no doubt other
...
places where this could be done.
2007-11-26 21:50:54 +00:00
d17db31213
Convert nulls to instances of a special NullValue class when we store them, and back again when retrieved. EHCache's replication mechanism flips out if you cache actual nulls (I have no idea why, nulls are obviously serializable). Also fix up some comments -- very soon we are going to have to add better (probably runtime) configurability to the Caches, and probably also write some code to display/collate their statistics.
2007-11-18 19:13:39 +00:00
8fbdf7470d
So while the JRE is happy to serialize arrays, EHCache is reluctant to do so in at least one place (presumably an explicit Serializable test). Let's switch to an ArrayList until further notice.
2007-11-11 20:29:38 +00:00
f052584607
This is actually starting to look hopeful. We have to add the cache replicator to each cache as we programmatically create them. Make sure we only do so when we have a distributed configuration.
2007-11-11 20:28:10 +00:00
934d7a28be
Implement the SQL 'exists' operator. I think this is our first serious subquery clause. Seems to work well.
2007-11-05 16:05:06 +00:00
3789164dae
Provide a constructor that takes a collection.
2007-10-26 23:03:32 +00:00
1dd1b52d3f
I made a mistake originally allowing IDENTITY value generators some partial configuration (e.g. start value and increment value). This only ever worked on PostgreSQL, and so would cause completely different behaviour under MySQL. That's obviously a bad idea.
...
So, IdentityValueGenerator's init() was meant only to be called upon table creation, but in r2234 I began calling it in all of a table's generators after every auto-migration. Needless to say this was bloody stupid, and caused MemberRecord's primary key generator to reset in production just now.
My fix is not to revert r2234, however, but to explicitly state init()'s expected behaviour: it should certainly not reset a generator if it already exists, but only ensure that it's operational -- creating it only if necessary.
We now never reset an IDENTITY generator, ever. The whole point of them is, after all, that they're auto-created by the database.
2007-10-18 01:50:11 +00:00
7bb36afef0
Don't assign default values to columns that have a @GeneratedValue annotation
...
because those will have their values set at insertion time and the database
might rightly freak out about the inconsistency of saying that the field has a
constant default value.
2007-10-17 00:42:17 +00:00
c68068fc33
If the search begins with non-word characters, the array returned by join() will have as its first element. We don't want in the array. So lo, we remove it.
2007-10-15 18:33:21 +00:00
f46aaf0152
I was the shadow of the waxwing slain.
2007-10-11 18:49:57 +00:00
85dbdecc0a
Oops, haha, this could've been amusing.
2007-10-11 18:31:49 +00:00
5bcfedf044
Match the changes in com.samskivert.jdbc.* by ridding ourselves of static column defining SQL strings. Also give ValueGenerators an option to calculate their initial value based on MAX() of the column for which values are being generated. As part of this we also make sure to initialize new ValueGenerators after all migrations take place, and add a way for them to clean up after themselves as well.
2007-10-11 18:14:49 +00:00
0b31aebb2e
Fixed @Transient handling.
2007-09-27 16:57:05 +00:00
46f0e751f3
Let's not downgrade our databases.
2007-09-26 21:40:18 +00:00
Michael Bayne