Roman Rokytskyy escreveu:

>> Better thing:
>> - if main file can't be opened, try open in read-only mode.
>> - if open succeed and the file is locked, continue
>>
>
> Yes, I was thinking about this option too...
>
>
>> For example:
>> - replication
>>
>
> You mean "hot standby"? Issue is that one need another config param
> saying how many transactions can be lost. In other words, commit on the
> main db should be blocked until difference in tx count in main and
> standby DBs is less or equal to this number. Otherwise feature is not
> controllable.
>

How exactly is subj. to a detailed specification. But NBAK engine is the
way to we have replication IMO.

>
>> - flash back queries
>>
>
> Why do I need NBAK here? I always thought that this can be achieved by
> providing a "flash back depth" parameter to garbage collector to prevent
> garbage-collecting those records and providing the "flash back"
> parameter with the query.
>

That implementation may also be possible. With NBAK, each delta locked
is a moment in the past.

>
>> - database "branches" - database with various independent delta files -
>> very useful for group of people developing/testing on one copy of big
>> production database without interfering with others
>>
>
> I like it :) We have to take care, since people might begin to ask for a
> "MERGE BRANCH <name> INTO HEAD" functionality - might be not very
> trivial to implement.

We need a type of merge.

We current have:
- one delta with database locked
- merge of delta to database

We need (for all the things I mentioned):
- one or more open delta (for branches) with possibly many locked delta.
Ex: db.fdb (locked), db.delta1 (locked), db.delta2 (locked), db.delta3
(open)
- a way to merge delta files with each others. Ex: merge (db.fdb,
db.delta1, db.delta2) - merge the db and the two delta files in db.fdb

--
Adriano dos Santos Fernandes
http://www.firebirdsql.org