Re: [dbunit-developer] [dbunit-dev] Evening meeting at my place - [SPAM E2 : Header] - Email found in subject

[Roberto Lo G. <rlo...@gm...>]

On Mon, Feb 14, 2011 at 17:00, Ashwin Kuntamukkala <AKu...@pd...
> wrote:

> Thanks Roberto for this comprehensive list.
>
> Could you throw some light on how we intend to support connection pooling
> if at all?
>

Yes, I think we should use the same connection to perform the setUp, the
test method and the tearDown so we can support transactions AND connection
pooling. This way a connection can be retrieved using any wrapper like dbcp.


> Also, currently we support DTD for schema. Are there any reservation
> against using XSD?
>

Not at all, I think DTD is quite obsolete and we should move to XSD, may be
even dropping DTD support. Should we vote for dropping DTD or just implement
XSD and eventually add DTD?


> Thank you,
>

You're welcome :)


>
>
> ______________________________________________________
>
> Ashwini Kuntamukkala  |  817.246.6760  |  ext. 4010 | mobile 626.354.2586
> *EPS Architecture Team ***
>
> *PDX, Inc.*
>
>
>
> *From:* rlo...@gm... [mailto:rlo...@gm...] *On Behalf Of *Roberto
> Lo Giacco
> *Sent:* Thursday, February 10, 2011 6:13 PM
> *To:* de...@db...; dbUnit Developers List
> *Subject:* [dbunit-dev] Evening meeting at my place - [SPAM E2 : Header] -
> Email found in subject
>
>
>
> Here are a few shots about the notes taken during the discussion
> http://dl.dropbox.com/u/8048150/dbUnit.pdf
>
>
>
> I'm very satisfied of what we have achieved this evening and I'm eager to
> read your comments about that.
>
>
>
> In summary, that few sketches state the following concepts:
>
>    - transaction management will be available as DatabaseOperation
>    wrappers, the autoCommit feature will remain available with the following
>    restrictions
>
>
>    - if test method is `transaction aware` (meaning it uses transactions,
>       say through hibernate or programmatic) and the test method starts a
>       transaction and commits/rollback the transaction then the setUp and tearDown
>       operation will be ran in their own transactions and committed upon the end
>       of their respective methods
>       - if test method is `transaction unaware` (meaning it doesn't use
>       transactions) then autoCommit will not be used and the setUp and tearDown
>       operations can use transactions to boost performances
>       - JUnit 3 users can use setUp and tearDown methods to declare their
>       transaction awareness on a per test case basis: this means no control on a
>       per test method basis
>       - JUnit 4 users will have a class/method annotation to declare their
>       transaction awareness on a per test case or a per test method basis,
>       whatever they prefer
>       - actual approach to transaction is good for almost all the users,
>       the real problem is regarding the InsertIdentityOperation which will be
>       replaced by the EL feature
>
>
>    - the DataSet structure will be completely abstracted by the format it
>    has been expressed, they will only carry the data and interfaces will no
>    more be required. In addition
>
>
>    - a new Schema structure will be introduced to better describe database
>       structure
>       - a few structures will be introduced to allow multi column primary
>       keys definitions, like PrimaryKey and ForeignKey
>       - some set-like operations will be introduced, like union(),
>       intersect() and difference()
>       - new Filter/FilterPredicate tree will be introduced to allow
>       dataset manipulation like ignoring some columns/rows, perform case
>       insensitive comparisons, etc... The filters should NOT create new datasets
>       but they should act as wrappers/proxy to be usable with streamed dataset as
>       well
>       - streamed dataset will be highly coupled to the low level reading
>       implementation which will act as a delegate
>
>
>    - having removed dataset format from the DataSet implementation a new
>    FormatHandler interface and consequent implementations will be introduced to
>    read/write dataset from/to files; streaming datasets will be highly coupled
>    to them
>    - new DataSetBuilder will be introduced to support programmatic
>    building of dataset
>    - new ExpressionLanguage will be introduced to support dynamic/flexible
>    datasets like http://pastebin.com/eMAzme75
>    - FormatHandler implementations will be retrieved through an abstract
>    factory which will be in charge of binding the ELParser (or any custom
>    extension) to the format handler so we can use one parser onto multiple file
>    formats
>    - Assert class will be improved and cleared as follows
>
>
>    - new set-like assertion methods like contains(), notContains(),
>       empty(), notEmpty(), etc... will be introduced
>       - assertions will be available on datasets only, no more dataset vs
>       table assertions will be available
>
>
>    - all the database specific stuff will be condensed into a
>    DatabaseDialect implementation following hibernate and jpa approach, among
>    the others:
>
>
>    - case sensitiveness issues
>       - type mapping, which will be extensible through a Java class first
>       and then through an xml conf file subsequently
>       - performance optimizations like disabling constraints
>       - per database or per driver custom solutions to any db related
>       issue: if it don't work on a specific database, this will be the
>       intervention point
>
>
>    - a visitor pattern implementation will be available to the database
>    dialect to traverse the dataset and find out the correct insertion order
>    trying to detect circular dependencies and all other long standing issues
>    - drop of the IDatabaseConnection interface and moving toward the
>    standard jdbc Connection interface: we don't need another connection
>    interface
>    - drop of the I prefix on interfaces and double check what interfaces
>    are needed (ITable, IDataSet, etc...)
>
>
>
> Conclusions:
>
>    - the next release will be designed from scratch, we think this evening
>    most of the design work has been done, few diagrams are available and they
>    will be transformed to UML class/sequence/component diagrams as soon as
>    possible;
>    - next step will be to write down a few test cases to prove our ideas
>    are practical and usable, they can be considered as usage examples and will
>    act as proof of concept;
>    - most of the actual codebase is still more than valid and we ended up
>    with the idea to avoid rewriting everything from scratch trying to reuse as
>    much as possible the existing code moving it into the new design thus
>    avoiding to repeat same errors or introducing new ones
>
> What is in this email IS NOT to be considered final, we welcome any comment
> and/or critique.
>
>
>
> We know there are a few things still to be evaluated, like spring friendly
> API, detailed annotations and much more... if you guys wish pick up some of
> those items and check the design against them it will be great.
>
>
>
> Thank you all,
>
>    Roberto
>