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
7fd42bc289
getFullTextIndex() is not expected to return null, so throw an informative
...
exception if it would rather than letting the caller NPE. Also switched to
the Zell-style single-letter studly _pClass.
2007-09-19 17:52:18 +00:00
fb5f44b92d
We need to look for FTI declarations in superclasses, too, just as we already do with @Entity indexes and @Table unique constraints. Ripped out the pointless RecordMetaData while I was at it. This is a lot cleaner.
2007-09-19 00:13:19 +00:00
acab65ac07
Aii, indexes and triggers reside in the database-wide namespace and have to be qualified. I'll need to cook up migrations for the places where we already use FTS...
2007-09-19 00:11:46 +00:00
0c4914db55
Added a standard traverse-and-filter cache invalidator.
2007-09-18 00:08:32 +00:00
f0f722ab7c
Ignore @Transient annotated fields when generating persistent field constants.
2007-09-17 18:23:40 +00:00
b2a3cd0f9a
Wrapped long lines.
2007-09-10 20:44:11 +00:00
45a03ed42d
Let's note what we're doing here.
2007-08-27 16:22:46 +00:00
8081e7bfad
Fall back to the simple case: a query on a concrete record without overrides can be stripped of all JOINs and external WHERE clauses in the second pass.
2007-08-27 16:11:26 +00:00
8e9279c242
We can't replace the original WHERE clause while keeping the original JOINs. Unfortunately, figuring out precisely which JOINs may be safely deleted seems rather complicated. For now, trust the database to do the right thing when our second-pass query is identical to the first one, except with an additional WHERE condition that restricts the primary key columns according to the results of the first pass.
2007-08-24 16:22:27 +00:00
d80cccd6bf
I'm assuming it's valid for a CachedValue to exist but have a null value as we
...
properly ignore those elsewhere, so we should ignore them when traversing the
cache as well.
2007-08-24 01:46:40 +00:00
b24786facd
More useful debug information.
2007-08-24 01:13:27 +00:00
cd6410ad7d
Let's not stick a fork in things if we don't have to. This is rendering Whirled
...
inoperable right now, but just returning what we got would be perfectly fine.
2007-08-24 01:07:45 +00:00
be3649908b
Replace insane implementation with one that does not rely on the database to magically know in which order we want results returned.
2007-08-22 20:30:20 +00:00
fa316d40d1
2007-08-22 18:19:40 +00:00
d652140afb
shadowOf is never null, rather it is the default value (PersistentRecord.class)
...
which we should studiously ignore.
2007-08-22 18:03:44 +00:00
97fed4e7d9
Yet another attempt at glorious audacity, after the realization that different kinds of clauses really do need to handle overrides differently. This should re-enable cache-friendly collection queries even on clones, which are the most complex things we do.
2007-08-22 17:44:06 +00:00
78f6ae51fd
Automatically bring any shadowOf class into play without an explicit FromOverride clause. This needs some more thought.
2007-08-22 17:40:48 +00:00
b1cdca0595
Even in load() we can be without a where clause, for e.g. loading a count(*) style record.
2007-08-22 17:18:15 +00:00
470c56d38c
If we declare an entity-level @Computed(shadowOf=...) then use that class as the default FROM table, duh.
2007-08-22 05:55:57 +00:00
a6f5211db4
Hack in a default value for integer types so that Postgres doesn't freak out
...
when we add a new non-null integer column. Maybe we should just specify default
values for all our integer columns, but decades of programming history point
toward zero as a pretty sensible default.
2007-08-22 02:40:44 +00:00
5191c6d967
Break a much gentler FieldDefinition out of FieldOverride. The former *must* be supplied for any computed field; the latter must *only* be supplied for fields that would otherwise reference concrete columns. This lets us be more intelligent about what we expand where. Also bring back the old semi-conservative selection criterion for two-pass cache-happy collection queries; it gets simply too hairy when parts of an object's primary key comes from a separate table.
2007-08-21 23:11:14 +00:00
3e96fb1d9a
Turn off field overrides when evaluating a join condition. This is all getting hairy -- sometimes you want FooRecord.BAR_C to point to the field 'under' the override, sometimes you want the actual overide expression. Hrm. Michael feels we probably shouldn't do any field expansion magic past the FROM clause. I am hoping we can preserve some of it in some intuitive way. This is a stop gap measure.
2007-08-21 19:06:55 +00:00
0cb937b14b
2007-08-21 15:07:07 +00:00
8e446fe93f
Generalize the automatic key value generation code so that it works on any column, and on any number of columns within a record.
2007-08-21 15:02:12 +00:00
60d63b13f1
Let's explain that a bit more hands-on
2007-08-20 18:54:40 +00:00
180b663b73
Fully respect the complexities of persistent records whenever we expand field references in a query. For example, a WHERE clause that operates on a field that's been overridden will correctly use the override. This is much more complicated than what we had before (which was fundamentally broken in its own way) so this patch could introduce strange behaviour. Please be on the lookout for SQL errors in your logs and/or data fields showing unexpected values.
2007-08-20 18:35:43 +00:00
6a608fcd6e
Roll back 2192 with comment.
2007-08-17 22:24:37 +00:00
Michael Bayne