Hi again,

Gene Sokolov responded to ODBC as a DB independence layer:
> I was thinking more in terms of defining a set of
> db-functions "the midgard way". I.e. an interface most
> suitable for midgard needs. And then mapping those calls
> to native db libraries or odbc calls. Making odbc the
> default db interface would certainly hurt performance.

The main point behind using ODBC and not a homegrown database
abstraction layer is to make the project more modular and standard's
conforming. Using available standards and implementations saves us from
the trouble of designing, implementing, documenting and maintaining
them.

The problem with ODBC is that it's quite heavy and slow when used the
way "Broken Shinai" does. The Midgard 2 architecture is more optimized
for ODBC (and any other generic db layer...). 

If someone knows a stable, widely-used and fast generic database
abstraction layer, then such a product could be used for our needs.
Perl's DBI is interesting but not available as a C library. If such a
product does not exist, then we'll have to use either ODBC or a layer of
our own.

If we're going to make a new database independence layer then I'd
recommend making it a separate product that would be generic enough to
be used by other projects as well.

> What are these smallint(5) types? Why 5? Is it an 80-bit
> unique id?

It is MySQL's 16-bit integer type. (5 is the display size.) This means
that the current schema only allows 64000 distinct records per table in
a midgard database. The ID fields can however be promoted to larger
INTEGER fields if needed. The Midgard library handles the ID's as 32 bit
integers. Midgard 2 uses globally unique 120-bit identifiers that are
stored as 20 base64-encoded characters.

> TEXT is rather short (< 32k) in postgresql too. And this
> limitation won't be fixed for another couple of months.
> That might be a serius problem.

The size of TEXT fields is not specified anywhere. The MySQL's 64k limit
has so far been the standard. There are few applications that need very
large TEXT fields and such applications could well use external storage.
So it is possible to use smaller TEXT fields. You'd just have to warn
users about it.

Another solution is to break the contents into multiple smaller TEXT
fields.

Jukka

--
This is The Midgard Project's mailing list. For more information,
please visit the project's web site at http://www.midgard-project.org

To unsubscribe the list, send an empty email message to address
[EMAIL PROTECTED]

Reply via email to