bb510ca506
Allow for distinguishing long-term caching from brief caching. For example, a public list of high scores may well lag 5 minutes behind database updates, whereas responses in a forum thread should perhaps never be more than 10 seconds out of date. The exact numbers are up to to the ehcache.xml configuration.
2009-02-06 16:09:10 +00:00
ce03952b3c
Javadoc fix, unused import nix.
2009-02-03 01:46:29 +00:00
db3dd861f4
Lose the spammy debug logging, collect some histogram information instead. These are not currently hooked up to Depot's Stat mechanism.
2009-02-02 18:14:26 +00:00
3b65bc9b01
The 50 ms warning triggers every couple of thousand stores for a relatively large cache, usually with times in the 60-70 ms range which is certainly acceptable as long as they're that rare. Let's bump it to 100 ms since we're still on guard for gremlins.
2009-01-29 16:38:52 +00:00
efb2799167
Let's accept ColumnExp's or Strings for field identifiers and handle SQLExpression field values too.
2009-01-28 18:32:42 +00:00
495399fc66
A little more information in our paranoid logging.
2009-01-28 05:54:23 +00:00
4cab181df0
We'll use a ConcurrentHashMap for the bin, and then the enumerator will make a copy of it for returning.
2009-01-26 22:20:48 +00:00
5a93e48e4d
Oops. Let's actually wire these guys up...
2009-01-25 00:16:09 +00:00
bbcf7c8607
Don't try to build the old EHCacheAdapter either, if we don't have ehcache.
2009-01-24 23:26:46 +00:00
9119cc9313
Update the test too.
2009-01-24 23:11:46 +00:00
9e41b41994
Bring back the old EHCacheAdapter for transitional use until we can figure out what's up with the new one. Also, the enumeration API changed again.
2009-01-24 22:54:03 +00:00
918405ec02
While investigating problems, add much paranoid profiling. Also let's do an explicit keyset copy during enumeration rather than the fancy concurrent hashmaps and iterable mappings. Finally, let's fully synchronize the other maps we're using.
2009-01-24 18:53:42 +00:00
db33c89b66
Get rid of some awful debug bits.
2009-01-23 19:51:12 +00:00
fc52b277a3
The CacheAdapter interface has changed:
...
* No more CacheBins, operations happen directly on the adapter.
* Each cache write must supply a CacheCategory value that identifies its type. Current values are RECORD, KEYSET and RESULT. We will probably need a MISC or USER or something along those lines, too.
The EHCache adapter has been entirely rewritten:
* Each CacheCategory maps to one EHCache, which means there are only a very few EHCaches, and we know what they are. We expect these to be declared in ehcache.xml rather than programmatically generated as before.
* Elements inside each EHCache are indexed by (cacheId, elementKey) tuples.
The main purpose of this refactor is to sort all Records into a single EHCache, which we can then make really, really large, and then let the LRU mechanism sort out what should be in memory and what shouldn't. The previous implementation would make no ram allocation distinction between busy records and ones rarely read.
2009-01-23 16:12:11 +00:00
07d848a3a0
Oops, we need to replicate what Depot does elsewhere to construct a database-unique identifier for the index.
2009-01-23 15:17:51 +00:00
c654606a2d
Add a convenience migration for dropping indexes.
2009-01-23 15:05:08 +00:00
0569f8f8ff
The buildIndex() magic expects an array of colums, not a list.
2009-01-22 16:43:21 +00:00
7dbc58d426
Function and Literal expressions can be non-deterministic but in most cases they are safe, and giving them proper toString()'s will help caching quite a bit.
2009-01-21 21:39:48 +00:00
017d9242ac
Better log message.
2009-01-12 15:13:34 +00:00
062a8efcac
Let the EHCache adapter be a little more configurable.
2009-01-10 01:47:11 +00:00
a5de1295f9
Let the EHCache adapter be a little more configurable.
2009-01-10 01:46:50 +00:00
a8b3e24e87
Allow caching to be skipped for single record loads, ensure that we don't cache
...
DepotMigrationHistoryRecord.
2009-01-09 21:40:30 +00:00
c46535cffd
Nixed unused imports, variables.
2009-01-08 22:15:46 +00:00
53358e74c9
Nixed unused import.
2009-01-08 22:08:35 +00:00
60c681ff74
Introduce a new cache strategy that does collection queries in two stages, but does not cache the keyset. This is a safe strategy, and we use it in places where an out-of-date result set is dangerous or annoying.
2009-01-08 18:22:40 +00:00
87b547743c
Moved some implemention detail clauses into impl.claus. I'd like to move
...
SelectClause in there as well, but peskily two things on MSOY are using it to
do subselects. I'd prefer there was some less "reaching into the internals" way
to do subselects.
2009-01-08 02:31:28 +00:00
a9c992bb44
Great big revampage: no more strings anywhere. It's all ColumnExps all the way
...
down (well, all the way to the public API anyway).
Revamped index creation while I was in there because that was one of the big
string users. Now you just put @Index on the field you want indexed, and if you
want a multi-column index you do things with a magical static method just like
we do for complex (function) indices.
@UniqueConstraint may still go away since it's basically exactly the same thing
as @Index(unique=true), so it's kind of pointless to support both.
2009-01-08 02:10:54 +00:00
a66f15e355
Minor edits.
2009-01-07 19:36:43 +00:00
f5fc65f1e1
More cache configuration options for findAll(), especially a new CONTENTS strategy which will cache the entire result set of the supplied query, without the restrictions of the KEYS approach. This is very lovely and perhaps a little scary.
2009-01-07 19:32:24 +00:00
269a3ffb92
Let's make this an insertion-ordered set so that all logically identical queries get assigned table abbreviations in the same order. This is mostly cosmetic, but has no significant cost.
2009-01-01 17:10:34 +00:00
68aac7fd11
Progress notification during migration soothes the soul.
2009-01-01 15:47:42 +00:00
c41534c7e6
We need these two fellows for the previous patch to make sense.
2008-12-31 00:59:28 +00:00
0ccd8bdb82
Extend our Index annotation to accept a 'complex' attribute. If an index ixFoo is marked complex for a given record, Depot will call the static method ixFooDefinition on that record class and expect a List<Tuple<SQLExpression, OrderBy.Order>> return value.
...
The purpose of all this is to create function (or expression, rather) indexes, which PostgreSQL does quite happily.
2008-12-31 00:25:29 +00:00
e3aed39330
Document our thrown exceptions.
2008-12-16 00:00:52 +00:00
44fd01cc2d
Switch to nulls here, too, making migration work right for HSQLDB.
2008-12-10 23:02:34 +00:00
b3cb1d6214
Cut and paste error.
2008-12-10 21:09:56 +00:00
50d31cfcc5
Unused import nixage.
2008-12-10 20:05:34 +00:00
f0f08f9516
More HSQL support:
...
- HSQL doesn't have full text search, so we just OR up a bunch of LIKE conditions to catch any and all matches. This is not efficient, but it'll do just fine for things like unit tests and development work.
- HSQL doesn't have & and |, it calls them BITAND and BITOR.
- HSQL doesn't have MySQL's unix_timestamp() or a way to get an 'epoch' from a date like PostgreSQL, so we count the number of seconds since 1970-01-01. I have not investigated to make sure this is exact, but it should at least be internally consistent.
- HSQL has a very neat list of data types that (no surprise) map very well to Java types.
2008-12-09 23:26:11 +00:00
96dfa3ca04
Break up the function that generates ColumnDefinitions for our fields and pass around a mutable instance of that object so as to give subclasses more freedom to do whatever weird stuff they need to to generate SQL for all the incompatible dialects out there. This is not elegant, and I feel this code along with ColumnDefinition and some of DatabaseLiaison, should pperhaps find a new home in the SQLBuilder structure.
2008-12-09 23:20:14 +00:00
b9bb84d3af
Cope with the new ColumnDefinition.
2008-12-09 23:18:17 +00:00
7eaaea15e7
Instead of enumerating columns for which values will be auto-generated and supplying magical DEFAULT arguments for them, simply don't include those columns in the insert.
2008-12-09 23:00:50 +00:00
cc07817238
Remove an ancient TODO: Get rid of SELECT FOR UPDATE and instead locklessly claim the next available primary key value.
2008-12-09 22:56:55 +00:00
817857d20e
HSQL doesn't think 'false' is a proper condition in a DELETE statement, and I suppose it has a point. This should always work.
2008-12-09 20:28:20 +00:00
76268a7fb1
This should have been deleted.
2008-12-01 18:17:14 +00:00
14a85d0de6
Differentiate between explicit queries and decomposed queries.
2008-11-25 22:02:15 +00:00
8ab95ec10e
Unconcretification of QueryClause. I concreted it a while back when it did
...
something and then those needs went away and now it's just a marker that
differentiates arbitrary SQLExpression instances from those that represent
clauses of a query.
2008-11-25 20:53:33 +00:00
8fec576663
Moved things that are not part of the Depot public API into an impl package.
...
Also moved WhereClause into depot.clause since it really wanted to be there.
2008-11-25 20:44:22 +00:00
980be19918
Unused import pruning and other cleaning.
2008-11-25 20:14:09 +00:00
0b439978fb
Stubbed out Depot support for HSQLDB. This also doesn't work yet but will some
...
day be made to work and enable more sophisticated unit testing of Depot and
systems that use Depot.
2008-11-25 20:13:43 +00:00
bc44c4e58e
A cache adapter for testing.
2008-11-25 00:57:22 +00:00
Par Winzell