db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ян Программист <webautoma...@gmail.com>
Subject Re: Google Summer of Code
Date Wed, 17 Mar 2010 13:15:30 GMT
Oh, yeah, the XML type in Oracle is for ORM stuff, that's for shure ;) John

2010/3/17 Ян Программист <webautomator@gmail.com>

> 2010/3/17 Ян Программист <webautomator@gmail.com>:
> >>  * No actual compatibility tests for Oracle, SQL Server
> >>
> >>
> >>
> >>   I imagine that there are some existing compatibility test suites out
> here. It would be interesting to understand Derby's compatibility with other
> databases. This sounds like a task >on which a GSoC student could make good
> progress.
> >
> >    Thanks,
> >    -Rick
> >
> Well, some useful compatibility features to focus on:
>    1. Converting data from one database to another in a respective way
>    against data consistency. The reasons why special software for converting
>    between different databases is useless. Problem of different actual length
>    of data in table cells. Acceptableness of creation and population of data
>    entries in additional tables with equal column structure for columns (read:
>    table schema) for entries with incompatible sizes (for column types of
>    consuming tables in a consuming database)
>    2. Converting data in a entity centric manner. Convert data of similar
>    column types from a point of stored data. If the database client code
>    contain strategy switching logic of how to interpret the state of data,
>    described in database, it is possible to populate entries in other tables of
>    consuming database to avoid loss of data consistency
>    3. Converting types is not always good. Compatibility is rather is if
>    consuming database would read entries with a special formatter - to
>    interpret data as it's own type. So you can copy data as binary heap and
>    force consuming database to enable special formatter to read data even at
>    production enviroment (formatter would rather point on certain points of a
>    cell data chunk in each number/word/... of actually represented data to
>    avoid dealing with useless binary delimiters). But that is for data types
>    which is for representing the same class (numeric-to-numeric, date-to-date).
>    Stored data in cells could be forced to converted to native to avoid usage
>    of special formatter, to use normal formatter when consistency of state of
>    entities(ORM?), represented in entries is ensured.
>    4. Column type compatibility is not an index compatibility. Source
>    database contains lots of indexes to speed the JOINs. So it is normally
>    required for consuming database to force indexing consumed data entries.
>    Index simply represent positions of cells, so in different databases it
>    would be different positions for the same data due to cell data size &
>    binary delimiters (a part of storage engine stuff). But delimiters are the
>    same for same storage engine, cell data sizes vary from to cell. Still do
>    not know how to fix a problem - but it would be awesome to apply, for
>    example, MySQL indexes on JavaDB without re-indexing on JavaDB side
>    5. I see a VARBINARY as a candidate for dealing with aggregation in
>    ORM. When you will need a convertion due to any reasons - you can get entity
>    data, described in ORM classes with ORM, where aggregated entities are
>    virtualised with referencing columns on either table, you can get entries
>    from aggregated table (entry of property set of entity) and store it into
>    VARBINARY of consuming database, and because it is known how the ORM class
>    entries would be iterated in tables of consumer database - you can read at
>    consumer side in a binary formatter, and use that data how you want.
>    Convertion of consumer's database VARBINARY to a set of columns as native
>    ones for aggregated entity entries is fast enough(?)
>    6. All that numeric precision delaing stuff. Yeap, ODBC NUMERIC type
>    will not have any sence if column compatibility would be implemented
>    (precision auto-dealing when reading from cells with different length (count
>    of digits) and float-to-int and other stuff). Can help avoiding some ODBC
>    code, as also as JDBC code, both relative to column type handling, when
>    accessing data from non-native database clients( access JavaDB from C# or
>    SQLite from Java, for example)
> *XML persistence driven conversions* of both schema and data and *"hot"
> binary copying* of non-native data from different databases(special
> formatters in (1)) are two main goals here. John

View raw message