Difference between revisions of "HSQLDB Integration"

From Apache OpenOffice Wiki
Jump to: navigation, search
m (Main HSQLDB Integration moved to HSQLDB Integration)
 
(18 intermediate revisions by 5 users not shown)
Line 1: Line 1:
Things to do for the HSQLDB integration in [[Main_OOo_Base| OpenOffice.org Base]]
+
This is a (more technically orientated) page about the integration of the [[HSQLDB]] engine[http://hsqldb.sourceforge.net/] into [[OpenOffice.org]].
* localize error messages (currently all hard-coded English)
+
 
* get rid of the "useDefaultSchema=true" parameter?
+
== Things To Do ==
 +
* [[HSQLDB_Localization|localize]] error messages (currently all hard-cod English)
 +
* get rid of the "default_schema=true" parameter?
 +
 
 +
== OpenOffice.org-specific settings ==
 +
Connection settings which are currently necessary to connect to HSQLDB embedded in an OpenOffice.org database file
 +
* '''storage_key''': unique key which globally identifies the connection/storage
 +
* '''fileaccess_class_name''': Name of the class implementing the file access
 +
* '''default_schema=true''': lets HSQLDB behave as if it doesn't support schemas
 +
 
 +
== Desired Features ==
 +
* single-file<br/>This would allow to get rid of the temporary files which are currently needed when working on the embedded HSQLDB, and thus remove some performance penalties
 +
* separation of the "auto increment" from the "primary key" concept. Currently, if you declare a column to be an auto increment column, it inevitable becomes the primary key
 +
* editable views<br/>Currently, if you create a view as simple as <code>SELECT * FROM table</code>, this is not updateable, even if <code>table</code> itself is.<br/>(side note: Hmm, have to check which part OOo plays here - perhaps it's OOo's fault in real?)
 +
* more tolerance when changing column definitions<br/>For non-professional users, it's quite common that a database schema is not defined once and then fixed, but instead evolves over time, as requirements evolve. HSQLDB currently is pretty restrictive in some areas, preventing some of such on-demand adjustments to the database.<br/>For instance, simply (?) changing the length of a column is prohibited as soon as the column is part of a relationship.
 +
* updatable result sets<br/>This would allow updatable views (wouldn't it?)
 +
* column aliases as variables, see {{Bug|66837}}
 +
 
 +
[[Category:HSQLDB]]

Latest revision as of 13:05, 28 March 2010

This is a (more technically orientated) page about the integration of the HSQLDB engine[1] into OpenOffice.org.

Things To Do

  • localize error messages (currently all hard-cod English)
  • get rid of the "default_schema=true" parameter?

OpenOffice.org-specific settings

Connection settings which are currently necessary to connect to HSQLDB embedded in an OpenOffice.org database file

  • storage_key: unique key which globally identifies the connection/storage
  • fileaccess_class_name: Name of the class implementing the file access
  • default_schema=true: lets HSQLDB behave as if it doesn't support schemas

Desired Features

  • single-file
    This would allow to get rid of the temporary files which are currently needed when working on the embedded HSQLDB, and thus remove some performance penalties
  • separation of the "auto increment" from the "primary key" concept. Currently, if you declare a column to be an auto increment column, it inevitable becomes the primary key
  • editable views
    Currently, if you create a view as simple as SELECT * FROM table, this is not updateable, even if table itself is.
    (side note: Hmm, have to check which part OOo plays here - perhaps it's OOo's fault in real?)
  • more tolerance when changing column definitions
    For non-professional users, it's quite common that a database schema is not defined once and then fixed, but instead evolves over time, as requirements evolve. HSQLDB currently is pretty restrictive in some areas, preventing some of such on-demand adjustments to the database.
    For instance, simply (?) changing the length of a column is prohibited as soon as the column is part of a relationship.
  • updatable result sets
    This would allow updatable views (wouldn't it?)
  • column aliases as variables, see Issue 66837
Personal tools