Subject Re: [Firebird-Java] Are there plans for streaming backup support?
Author Ivan Arabadzhiev
Thanks for responding :) I haven't really been through the FB code so I was hoping when you get the chance you'd lend a hand - chances are I'll need a few days just to figure out what I'm reading. The only part I'm sure about is that the length argument is 2-bytes wide because it is explicitly stated in the README and in the discussion for the .Net provider. Either way, I'm hoping any change would keep some different part of the code from malfunctioning, rather than break the restore.
On that note, I also don't like assuming an order of the elements in the buffer, so that will have to come 'any day now'.

Is for available(), I wasn't really happy with it either (which is why I didn't start with it). The change in question is . I think I could add some 'random' element to the bytes requested and try to beat some sense to InputStream that way.

You will have a scanned license agreement by the end of the week but for now I want to spend any possible time on polishing the code. However, since you mention it - I'm guessing I should copy the initial comment from the other files, but do I copy it with the names or do I fill myself in (never really wanted to document my existence , but I am willing to take the blame for any possible headaches caused by my code :))

2016-02-17 11:34 GMT+02:00 Mark Rotteveel mark@... [Firebird-Java] <>:

On 16-2-2016 13:37, Ivan Arabadzhiev intelrullz@...
[Firebird-Java] wrote:
> Hi,
> So far so good but it is terribly slow so I reworked the backing up to
> enable a bigger buffer - will push as soon as I find out what I broke in
> restore ...
> I'm thinking multi-file split can be done simply by closing fileN at X
> bytes and opening fileN+1. Might not be 100% what gbak does but the API
> shouldn't really care if I have a single file on disk or I store every
> byte on a different media. That being said, I've never needed the
> functionality myself and don't know if people actually use it often
> enough to need a default implementation.
> As for the change - perhaps I should've given
> to begin with. addArgument(isc_info_svc_line, bufferToBeAdded); throws
> an exception otherwise.

Aha I see what you mean, I think I will need to do some digging in the
Firebird code, because I am not entirely sure if this is the right solution.

For one, maybe isc_info_svc_line should be identified as a Wide type,
and I am not sure if the exclusion of StringSpb there is right.

Mark Rotteveel