> > 1) talk a little bit
> > 2) create a read-only datastore
> > 3) go through how to use (can copy the examples directly)
> You already made a start at this here:
> http://docs.geotools.org/latest/userguide/tutorial/advanced/contentdatastore.html.
> Should I keep all that or toss it out and start over or ... ?
Keep adding to that page.
> > 6) talk about performance and show a couple performance examples (cache
> > bounds and number of rows for example)
> Uh, yeah. I haven't thought about performance at all. If we simply 'copy'
> some of the tricks from the AbstractDataStore tutorial, that seems a bit
> silly.
>
>
Not really; we want to show how ContentDataStore allows you to "cache" a value
in your own ContentState class stored per transaction. Rather than what
AbstractDataStore did which had people set up
Map<Transaction,Map<String,Object>> repeatedly. That is Transaction -->
typeName --> cached value.
> In fact, that reminds me I've been meaning to ask: Shouldn't we explicitly
> describe the differences (and pros and cons) between AbstractDataStore and
> ContentDataStore? There's a short Note at the beginning of the CDS tutorial,
> but it doesn't really describe the differences in detail and doesn't answer
> why/when you would want to use one vs the other.
Right; Perhaps we could have a table comparing the two?
>
>
There are also two pages to compare for this discussion here:
- http://docs.geotools.org/latest/userguide/library/main/internal.html (shows
abstract datastore class diagram)
- http://docs.geotools.org/latest/userguide/library/data/internal.html (shows
content datastore class diagram)
- http://docs.geotools.org/latest/userguide/library/jdbc/internal.html (shows
how jdbc datastore extends content datastore)
What we don't have (because it is scary) is a picture showing how abstract
datastore is extended; perhaps I could do one for PropertyDataStore.
>
> > 7) Construct JUnit test case
> (extending a base JUnit "conformance" test case with if we are really cool)
> Sure. I created several tests as part of writing the CSV support (see
> CSVDataStoreTest). I'm not sure what you mean by "base JUnit conformance
> test" -- please explain.
Sure; see the MemoryDataStoreTest? It defines a whole bunch of test cases
(basically used by me to convince myself the datastore api works). Those test
cases have been copied and pasted and adapted in as people have written
additional datastores.
Justin got sick of that hap hazard approach; and for JDBCDataStore he wrote a
JDBCDataStoreTest case which implementors could resuse. So by extending this
base JDBDataStoreTest case you could make an H2DataStoreTest case for example.
One thing that enabled him to do this was the addition of the createSchema
method; my understanding is he can create a table, populate it with data, and
then run one or more tests against it. When an implementor has their code
passing all these tests Justin has provided they can be pretty sure they are
done.
Jody
------------------------------------------------------------------------------
vRanger cuts backup time in half-while increasing security.
With the market-leading solution for virtual backup and recovery,
you get blazing-fast, flexible, and affordable data protection.
Download your free trial now.
http://p.sf.net/sfu/quest-d2dcopy1
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
