Re: [gnome-db] SqlBuilder feedback

Vivien Malerba <[email protected]>
Newsgroups gmane.comp.gnome.db
Message-ID <[email protected]>
2009/11/9 Murray Cumming <[email protected]>:
> 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 <[email protected]>:
>> > > 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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.