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