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
fb259504c9
2007-08-16 20:26:12 +00:00
a794805a86
Another place where it's safest to be explicit about whence the column comes.
2007-08-16 20:24:15 +00:00
94766648e6
We have to carefully convert the user's query input to the boolean lexeme language TO_TSQUERY() expects. We may ultimately have to do more complicated things here, too.
2007-08-16 16:54:52 +00:00
cf8a977778
Add the primary key on columns, not fields.
2007-08-15 22:18:54 +00:00
d414292ac3
Let's not force validation on every Tom, Dick and Harry. This is a little
...
verbose, so maybe I'll change my mind again later and do something yet again
different.
2007-08-15 19:47:16 +00:00
a68a6534a4
More sanity checking.
2007-08-15 19:03:47 +00:00
0175081c54
2007-08-15 19:00:50 +00:00
8e13453362
Added some sanity checks to notice and catch programmer errors as early as
...
possible.
2007-08-15 18:44:35 +00:00
b884f89e80
If a persistent record is abstract, do not generate ColumnExp() constants for
...
it; if it extends another record, generate ColumnExp() constants for persistent
fields inherited from its parents.
2007-08-15 02:39:42 +00:00
a13756eec3
Make sure the record in question is not computed.
2007-08-15 01:16:02 +00:00
ab8ee79dbe
The logging output already contains the enclosing method name. So instead of
...
repeating the method name:
2007/08/14 16:07:52:157 INFO PersistenceContext.cacheStore: cacheStore: entry [key=...
we'll just say what we're doing:
2007/08/14 16:07:52:157 INFO PersistenceContext.cacheStore: storing [key=...
2007-08-14 23:18:22 +00:00
8e916489e0
Brevify our toString() output so that cache debug logging is readable.
2007-08-14 23:15:08 +00:00
34d1e73976
Return the string value of our cached value as our own.
2007-08-14 23:12:53 +00:00
589045232c
Add a mechanism for warning about records that are lazily initialized after an
...
attempt has been made to resolve all registered records.
2007-08-14 21:35:38 +00:00
Michael Bayne