Difference between revisions of "HSQLDB Integration"
From Apache OpenOffice Wiki
m (Main HSQLDB Integration moved to HSQLDB Integration) |
B michaelsen (Talk | contribs) |
||
(18 intermediate revisions by 5 users not shown) | |||
Line 1: | Line 1: | ||
− | + | 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- | + | |
− | * get rid of the " | + | == 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 asSELECT * FROM table
, this is not updateable, even iftable
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