If something should be listed and is not, it is an oversight.

Fixes and upgrades are listed on the web site change log page.

There is no work schedule. Work tends toward whatever seems interesting at the moment.

There are no known bugs simply because, when a bug or a break is discovered, all other work ceases until it is fixed.

These are intended and are only waiting on a rainy day and a round tuit.

Parentheses :
      At this point in his development, AxleBase is overly critical of unnecessary parentheses. When a superflous parenthetical enclosure is encounterd in a "where" clause, he will complain.

SQL optimizer :
      Needs more work.

Joins :
      Compound parenthetical joins are not yet supported.

Joins :
      Group by and having are not done.

Math operations in SQL statements are not done.

Unique selects are not done.

Disk management :
      Take more control of the disk from the operating system to reduce file fragmentation and increase speed.

Concurrency :
      Develop a concurrent-load test that can break AxleBase to find the maximum number of concurrent users that AxleBase can handle.

A decision has not been reached on whether or not to do the following items.

Column locks.

Computed columns.

Table constraints :
      Only the primary key constraint is currently operational.

Jobs :
      Commonly known as "stored procedures".
      ( The use of SQL as a programming language is a dangerous practice, but it is common, so this is undecided.)

Index improvement :
      A method has been found for improving the index tremendously. However, if the time to find a record out of a trillion is reduced from two minutes to one, is the effort worth it?

Table Size :
      Implementation of the original plans can expand table size by thousands of times, which i doubt that the big names can copy without major expenditures.
      But my research in this area seems to be done, my points about languages, computers, and one-man-development are demonstrated, and those sizes could not even be tested. So...?

There is currently no intent to build these items into AxleBase. (Items have disappeared from this section through the years only because they have been done by accident. Seriously.)

Miscellaneous

_____________	_____________	_____________
any	declare	some
arrays	escape	sub-selects
cross joins	exist	starting
case	for update	transactions
cast	lower	triggers
collate	merge	union
containing	plan	upper
current of	singular	using

AxleBase will not accept "joins" in the "where" location or "wheres" in the "join" location. Wheres must be in the where clause and joins must be in the from clause.

Since a host app can modify data that has been returned, there is little need for that in AxleBase queries and it has a very low priority. For example, applying a date conversion to a column after it is selected can be done by the host.

Century leap-seconds are not handled in date functions.
      It was considered only because the CoreDate protocol allows AxleBase to define such a large segment of time, 20,000 years. It is ignored because the technological ability to calculate the number of femtoseconds since the beginning implies a reality and accuracy that mislead the masses.

AxleBase does support the ODBC protocol.
But the drivers are designed for each host and so must be the responsibility of the host developer.

See the discussion of the axsys in the documentation's VLDB chapter. The axsys can mirror a database faster than any other known method. Otherwise, mirroring is not currently a consideration, but this may be re-evaluated.

Slave databases: See above.

Failover databases: See above.

Backup databases: See above.

This has been known by various names through the years such as transaction logging and journaling with checkpointing. Its purpose is database restoration from the checkpoint.

The objectives of AxleBase do not require journaling and they might actually be impaired by it. It could, for example, seriously degrade the speed of a very large database. It would be simple and a fun bit of programming, but is not seriously considered because of its negative impact on operations.

This may be reconsidered if journaling is found to be of appreciable benefit to the management of very large data objects.

Since the mechanism for views would not be complex, this might be reconsidered, but views might be dangerous. A view is a software operation that is run against the involved tables every time that the view is referenced. AxleBase is designed for databases containing very large and geographically distributed tables, and creating views with such objects could be disruptive or even catastrophic.

__________________________________________________

Copyright 2003 - 2012 John Ragan

Web site maintained with Notepad and command line FTP.