уже сколько я бранюсь по поводу NotesStream ...
все как-то не очевидно
Очередной раз потратил кучу времени (искал ошибку). Решал задачу запуска обработки на сервере. Использовал либу (кот. выкладывал здесь) для передачи UNID в виде текста и обработки
Напомню - либа может:
- создать файл с UNID по NotesDocumentCollection
- обратно преобразовать (NotesDocumentCollection -> UNID файл)
- раз/зиповать файл
Смысл действий - если коллекция "очень большая" нужна (у меня было 300 000 доков) для обработки, гонять из клиента - ждать "вечно". Архивация (zip) вполне себе шаг для такого кол-ва текста
Результатом получается вполне себе массив, кот. может не уместиться в памяти...
Тут мы переходим к NotesStream - спокойно пишем в него, открывая как
stream=New ses.CreateNotesStream
возврат результата (списка юнидов), ожидаемо, надо слить в файл, тут первые грабли
-
нельзя у стрима, в кот. писали, задать файл ("известный" момент)
ну мыж могем и перелить в другой
Код:
...
newstream.open(path)
...
buf=stream.read(bufsize):newstream.write(buf)
...
а записывали мы (надо заметить, перед этим) как stream.WriteText(STREAM_LINE, EOL_LF)
дело было на linux (сервер) и кодировка UTF-8 (что какбэ не смущало) - это влияет на newstream.open
результатом кода получим интересный файл (см. приложение)
фокус в том - что при считывании как Readtext(STREAM_LINE, EOL_LF) трудно получить юниды
там будет 2-х байтовый месс
не так очевидно, но возможно
тогда решаем делать
Код:
buf=stream.Readtext(STREAM_LINE, EOL_LF):newstream.WriteText(buf, EOL_LF)
и получаем вторыми граблями - LF продублируются
(сумки драные)
это не критично для либы, но "обидно" для прерфекционизма
отмечу: при считывании с LF - знак LF попадет в буфер