Re: [gnome-db] SqlBuilder feedback

[Vivien Malerba <vmalerba gmail com>]

2009/11/9 Murray Cumming <murrayc murrayc com>:
> On Mon, 2009-10-26 at 18:21 +0100, Murray Cumming wrote:
>> On Mon, 2009-10-26 at 10:04 +0100, Vivien Malerba wrote:
>> > 2009/10/25 Murray Cumming <murrayc murrayc com>:
>> > > I've looked at the new GdaSqlBuilder API and I have some thoughts.
>> > >
>> > > Firstly, I think that the IDs are exposed too often. I can see how the
>> > > ID could have some use to an application programmer, but it should not
>> > > be the main way to use the API.
>> > >
>> > > At the least, this (pseudo-code) is annoying:
>> > >  gda_sql_builder_add_field(builder,
>> > >    gda_sql_builder_add_id(builder, 0, "sometable.somefield") );
>> > >
>> > > This would be nicer:
>> > >  gda_sql_builder_add_field(builder, "somefield",
>> > > "sometable" (optional))
>> > >  would be nicer.
>> > >
>> > > In subsequent calls, GdaSqlBuilder would use the same ID automatically.
>> > >
>> > >
>> > > The current API gets even more long-winded when dealing with values too,
>> > > for UPDATE commands:
>> > >  gda_sql_builder_add_field(builder,
>> > >    gda_sql_builder_add_id(builder, 0, "sometable.somefield") );
>> > >    gda_sql_builder_add_expr(builder, 0, NULL, 123) );
>> > >
>> > > This would be simpler:
>> > >  gda_sql_builder_add_field_value(builder, "somefield",
>> > > "sometable" (optional), 123);
>> >
>> > Using ID allows the API to be kept to a minimum number of functions,
>> > while allowing one to build very complex statements, so I want to keep
>> > them as they are, but I agree there is a need to have some more "daily
>> > usage" API to have less lines of code. There are 2 ways of doing this:
>> > either create some real functions or use macros. Even though I like to
>> > keep the number of methods to a minimal, using macros here can lead to
>> > difficult debugging times as the macros could get complex, so I
>> > propose to add new "higher level" API, starting with:
>>
>> I can't imagine why you would ever want to use macros instead of
>> functions. That way lies madness.
>>
>> > void gda_sql_builder_easy_add_field (GdaSqlBuilder *builder, const
>> > gchar *field_table, const gchar *field_name, GType type, ...)
>> > and
>> > void gda_sql_builder_easy_add_field_value (GdaSqlBuilder *builder,
>> > const gchar *field_table, const gchar *field_name, GValue *value)
>>
>> I hate the use of "easy" in API names. Just make it easy - you don't
>> need to call it easy. That just makes the API look weird and
>> inconsistent.
>>
>> I would append _id to the existing functions, so, for instance:
>>   gda_sql_builder_add_field()
>> would become
>>   gda_sql_builder_add_field_id()
>> and then add real gda_sql_builder_add_field() and
>> gda_sql_builder_add_field_value() functions like above, but without
>> "easy" in their name.
>
> Thoughts? I don't want to give up on this API. It could be very useful
> in glom an in general.
>

I just did not have the time to implement the API, I've been working
on a new provider which
has eaten way more time than I had anticipated.

Vivien