SqlBuilder feedback

[Murray Cumming]

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);

--
murrayc@...
www.murrayc.com
www.openismus.com

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

[Vivien Malerba]

2009/10/25 Murray Cumming <murrayc@...>:

> 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:

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)

What do you think?

Vivien
_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

[Murray Cumming]

On Mon, 2009-10-26 at 10:04 +0100, Vivien Malerba wrote:

> 2009/10/25 Murray Cumming <murrayc@...>:
> > 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.

 
--
murrayc@...
www.murrayc.com
www.openismus.com

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

[Murray Cumming]

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@...>:
> > > 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.


--
murrayc@...
www.murrayc.com
www.openismus.com

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

[Vivien Malerba]

2009/11/9 Murray Cumming <murrayc@...>:

> 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@...>:
>> > > 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
_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

[Murray Cumming]

On Wed, 2009-11-25 at 22:36 +0100, Vivien Malerba wrote:

> >> 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.
> >
>
> You can now check commit
> http://git.gnome.org/cgit/libgda/commit/?id=9ecb4bc9f8d4cfc2dad31a5109b610f6988c2fd9
> which has the new API.

Thanks. That's much better.

How about doing the same for the other functions, such as
gda_sql_builder_select_add_target(), gda_sql_builder_add_cond(), etc?

I can do that if you like.


--
murrayc@...
www.murrayc.com
www.openismus.com

_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list

[Vivien Malerba]

2009/12/2 Murray Cumming <murrayc@...>:

> On Wed, 2009-11-25 at 22:36 +0100, Vivien Malerba wrote:
>> >> 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.
>> >
>>
>> You can now check commit
>> http://git.gnome.org/cgit/libgda/commit/?id=9ecb4bc9f8d4cfc2dad31a5109b610f6988c2fd9
>> which has the new API.
>
> Thanks. That's much better.
>
> How about doing the same for the other functions, such as
> gda_sql_builder_select_add_target(), gda_sql_builder_add_cond(), etc?
>
> I can do that if you like.

That'd be great, yes.

Thanks,

Vivien
_______________________________________________
gnome-db-list mailing list
gnome-db-list@...
http://mail.gnome.org/mailman/listinfo/gnome-db-list