В-целом то я согласен с тобой.
Есть частности - например, при выгрузке результата запроса количества строк я не знаю.

[quote author=kms link=1214205575/240#242 date=1215728213]
Ну, наверняка чего-то будет не хватать, вот жду этого момента. :)
На выгрузке из строки ИТ в вектор пока пожеланий не проявилось.[/quote]
ИМХО нужно переделать выгрузку/загрузку из ИТЗ на этот интерфейс, сразу и проверим его правильность :)

[quote author=kms link=1214205575/240#242 date=1215728213][quote author=orefkov link=1214205575/240#241 date=1215717470]В-целом то я согласен с тобой.
Есть частности - например, при выгрузке результата запроса количества строк я не знаю.[/quote]
Ага, понял. Тогда вот так пока:
[code]
     // источник может передавать 0, если количество не определено
     // приемник может возвращать 0, если ограничений нет
     // если приемник реально не может принять данные, пусть возвращает ошибку
     virtual HRESULT ldrInit(DWORD& nColCount, DWORD& nRowCount) throw() = 0;
[/code]

Пошел пока путем максимального упрощения, чтобы понять чего не хватает.
Понял пока вот что:
- "ПараметрыДляПриемника" - так и не захотелось использовать.
Вижу, у тебя используется для параметризации очистки, но в общем случае у меня получается параметров больше.
Например, я хочу загружать данные в строку или колонку ТЗ, при этом могу обрезать исходные данные до одной строки, а могу слить все строки в одну - и т.д.
Короче, прокси-объекты в качестве кастомизированных приемников представляются предпочтительными.

- setColumn упростил в пользу AddColumn - применения colIdx не нашел.

- Вот что хотел спросить у тебя - assignRetValue - тоже не вижу применения.
У меня все приемники - это живые контексты, после выгрузки - это контексты с данными.
Нужен ли будет assignRetValue?

P.S.
Ну, наверняка чего-то будет не хватать, вот жду этого момента. :)
На выгрузке из строки ИТ в вектор пока пожеланий не проявилось.[/quote]

Так, по порядку.

Зависимости текущего интерфейса от sqlite нет - параметр объявлен указателем на предварительно продекларированную структуру sqlite3. Как говорится - не нужен, не используй. А мне для будущего развития может пригодится.

Виртуальный деструктор - ну это я по привычке, gcc любит ворнинги кидать, когда класс с виртуальными функциями не имеет виртуального деструктора.

AddRef/Release тоже ни к чему - мой метод выгрузки нисколько не собирается сохранять ссылки на объект приемник либо удалять его.

Параметры для приемника - ну, тебе не нужны, а мне допустим нужны. Если они есть, то хуже не будет - позволяет реализовывать более гибкие сценарии использования.

Присвоение возвращаемого значения: опять же твой сценарий - это очень частный случай.
Посмотри например у меня IScalarResultLoader.
К тому же какой код проще:
[code]
Приемник = СоздатьПростейшийЗагрузчикВоЧтоТо();
запрос.Выполнить(Приемник);
Результат = Приемник.ПринятыеДанные();
[/code]
или
[code]
Результат = запрос.Выполнить(СоздатьПростейшийЗагрузчикВоЧтоТо());
[/code]?

setColumn vs addColumn
colIdx у меня используется в IVTResultLoader.
Даже если посмотреть общую семантику интерфейса - раз в методе init уже указывается количество колонок, то далее нужен именно set а не add. В первоначальном варианте интерфейса у меня как раз было так - в init количество колонок не указывалось, и был метод addColumn. Однако когда я начал реализовывать загрузчик не в пустую ТЗ, а уже содержашую колонки - вот тут и пришлось изменить интерфейс.

Ограничение количества принимаемых строк - делать в инит имхо неверно - приемник может не знать, сколько строк ему надо выкачать, но должен иметь возможность остановить приемку (например, приемник с какимнить условием типа "Пока общий итог сумм документов меньше 100000").
Я собирался изменить void addValues на BOOL addValues - при возврате FALSE остановить выгрузку.

Вот примерно так.

И такой вопрос
Даже перейдя на IUnknown-ые интерфейсы, остается вопрос перехода от CValue/CBLContext к IUnknown, те тот же rtti и dynamic_cast. Так стоит ли овчинка выделки?

[quote author=kms link=1214205575/240#246 date=1215765340]
[quote]
И такой вопрос
Даже перейдя на IUnknown-ые интерфейсы, остается вопрос перехода от CValue/CBLContext к IUnknown, те тот же rtti и dynamic_cast. Так стоит ли овчинка выделки?[/quote]
Да вот не знаю пока.[/quote]
ИМХО IUnknown пока не нужно, ведь в дальнейшем при необходимости нам никто не мешает нарастить каркас для этого интерфейса, объединив в каком-то промежуточном прокси-объекте интерфейс IUnknown и наши интерфейсы.

Да, я подумал еще и во многом с тобой согласился.
С addColumn ты прав.
Действительно, в моей реализации IVTResultLoader::setColumn я полагаюсь на последовательный перебор индекса с выгружающей стороны.
Присвоение значения - спецефическая мулька ВыполнитьЗапрос, и может быть реализована совершенно другим интерфесом, равно как и доп.параметры. Да и вообще я в ВыполнитьЗапрос доп параметры уберу.
Кому надо, чтобы ТЗ или СЗ очищались - пусть предварительно пишут - Очистить(), УдалитьСтроки(), УдалитьВсеЗначения().
Ща накидаю свой вариант интерфейса.

Вот допустим примерно так:

class IInterface
{
public:
	virtual void AddRef() = 0;
	virtual void Release() = 0;
	enum errCodes{
		success,
		memError,
		// Другие базовые ошибки
		firstErrForChilds
	};
};

class IErrorDescription : public IInterface
{
public:
	virtual errCodes lastError(CString& errDescr) throw() = 0;
};

class IValuesDataDestination : public IInterface
{
public:
	enum myErrCodes{
		dontWantMoreData = IInterface::firstErrForChilds,
	};
	enum{
		unLimRows = 0,
	};
	virtual errCodes init(DWORD& colCount, DWORD& rowCount) throw() = 0;
	virtual errCodes addColumn(LPCSTR colName, const CType& type) throw() = 0;
	// Нельзя менять ни адреса в массиве указателей, ни сами значения
	virtual errCodes addValues(CValue const* const* ppVals) throw() = 0;
};

class IValuesDataSource : public IInterface
{
public:
	virtual errCodes dataInfo(DWORD& colCount, DWORD& rowCount) throw() = 0;
	virtual errCodes columnInfo(DWORD colIdx, CString& colName, CType& type) throw() = 0;
	virtual errCodes nextValues(CValue const* const* &ppVals) throw() = 0;
};

class ISQLiteParamModificators : public IInterface
{
	virtual errCodes columnModificator(DWORD colIdx, int& mod) throw() = 0;
};
 

Обсуждаем дальше.

Саша, меня интерфейсы почти устраивают.

ОДно но:
Михаил, Саша, а нафига нам коды ошибок вообще?
Я лично нигде, кроме AddValues, не вижу необходимости для них.
Можно ведь вернуть TRUE или FALSE в каждом методе, а для получения точной инфы в случае возврата FALSE можно обратиться к интерфейсу получения данных об ошибке.

Все равно нельзя предугадать заранее все коды ошибок для будущих объектов.