In-memory database - opening read-only database from memory rather than from
file in FB Embedded
------------------------------------------------------------------------------------------------
Key: CORE-3642
URL: http://tracker.firebirdsql.org/browse/CORE-3642
Project: Firebird Core
Issue Type: Improvement
Components: API / Client Library
Affects Versions: 2.5.1
Reporter: Dmitry
Replacing application-internal data stractures with some data warehouses has a
long history.
Once it was in-memory ISAM tables with manual sorting/indexing
As CPU/memory increased, solutions like generic SQLite(having 'in-memory' mode)
or language-specific NexusDB/sqlMemTable appeared.
Latter has drawback that when new Language version is rolled out they usually
lag behind for quite a while.
SQLite is popular, but not as feature-rich as FB and language-specific access
components might be worse for some languages (especially Delphi lineup) than
for FB.
However generally converting file-based database into memory-based would be to
complex goal to worth doing/asking for. But not now, i feel.
General Temporary Tables were introduced into FB quite ago. And with 2.5.1
release GTTs can be used fully even in generally read-only database.
So all the code for in-memory tables, indexes, views etc is in place.
Metadata can't be changed but it arguably may apeear 'right thing' for the
in-memory database: not using 'db genearator script' but using readymade
database file with ready-made data access components bindings. Also this aligns
well with Windows restriction that in-memory file should have pre-defined
length and never grow (if implementation would use file handles API for
bootstrapping, this easy way is okay probably, since 'tis only needed to read
headers once on r/o database).
What i feel is left to be implemented:
1) database file opening from memory in FB Emb
1.1) either only-r/o databases
1.2) or every database, if pened 'in-memory' should be treated effectively r/o
All the actual work is to be shared between persistent
VIEWS/TRIGGERS/PROCEDURES
2) bonus: UDF support in-memory. Not via extra files but again via function
pointers
Nice thing, though not necessary, and can be done anytime later.
3) bonus: EVENTs posting via common connection stream (X-NETc in-memory stream
for FB-Emb), rather than separate TCP connection.
This can start as FB Emb optimization (TCP requirement for an application to
talk to itself is curious artefact) and later generalized into FB-generic
enhancement (as done in IB7.1sp1).
While this may made diagnostic sometimes more complex, it would made system
configuration a bit easier
This change can be done anytime later as well.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://tracker.firebirdsql.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn
about Cisco certifications, training, and career opportunities.
http://p.sf.net/sfu/cisco-dev2dev
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
