(In reply to comment #0)
> gnumeric 1.9.17 does not build with libgda 4.1.3:
> 
> checking for GDA... yes
> checking libgda/control-center/gdaui-login-dialog.h usability... no
> checking libgda/control-center/gdaui-login-dialog.h presence... no
> checking for libgda/control-center/gdaui-login-dialog.h... no
> 
> 
> The control-center headers are not installed by libgda, maybe they are
> internal?

Hi,

I have exactly the same with gnumeric 1.10.0

I tried libgda-4.1.4 and libgda sources taken from git as well but control-center/gdaui-login-dialog.h is never installed.

I tried to copy control-center/gdaui-login-dialog.h into include/libgda-4.0/libgda but it doesnt help.

Regards,
Marcin

This code must be rewritten to follow the changes in the gda API. Will need gda-4.2.x.

Created attachment 165256 [details] [review]
Initial patch

This makes build work again, but things don't work yet.

Feel free to commit if you feel this improves the situation.  I am not
able to evaluate this.

As things still don't work, it's better to leave thigs as they currently are. Having menus which do not do anything useful would be worse.

The problem is caused by a transitional patch:

http://mail.gnome.org/archives/commits-list/2009-November/msg01194.html

Currently, this plugin does not work. Before we find a way to make use of the new API, please revert this patch to make the old libgnomedb-3.0 work. However, I still hope this plugin show up in next version, since libgda4.x is an obviously better solution.

There is no chance that next release can work with libgnomedb-3.0 since they don't use the same gtk+ major version. We need to use a recent libgda version.

These days the current version of libgda is 5.x.  (5.0.0 was released over a year ago, in October 2011.)  It would be really nice to update Gnumeric to work with this version of GDA.

Created attachment 250543 [details] [review]
Bring GDA plugin back, the initial version

Hello,

I've prepared a patch that brings the libgda support back and makes the GDA
plugin available.


Tested on
---------
1. Debian sid amd64
2. PostgreSQL 9.1.9
3. SQLite 3.7.17


Requirements
------------
1. libgda-5.0 >= 5.0.0
2. libgda-ui-5.0* >= 5.0.0

*Important: my Debian sid doesn't provide the libgda-ui part in the packages,
I've built it manually from git.


Test scenario
-------------
1. Create one or more GDA Data Sources (using gda-control-center-5.0)
2. Open Gnumeric (assuming that the plugin is already built and installed)
3. Select a region, type a sample query, like

   =readdbtable("MyDSN","MyUsername","MyPassword","MyTable")

   or

   =execsql("AnotherDSN",,,"SELECT Something FROM Sometable")

   and press Ctrl+Shift+Enter

4. GDA login dialog appears, confirm the settings and click "Ok"
5. Data should appear on the worksheet.


Good news
---------
It even works with PostgreSQL and SQLite, when you specify initially *correct*
arguments to readdbtable()/execsql() functions. When you query the same DSN with
the same connection arguments from the spreadsheet, it even will not show the
login dialog again, because the plugin caches the connection information.


Bad news
--------
It works ONLY when you specify initially *correct* arguments to readdbtable()
and execsql() functions. It will not work otherwise, and now I will try to
show, why.

During the debugging sessions I've noticed that plugin queries the database
more than once, even if I typed the execsql()/readdbtable() once in the cell.

After analyzing the control flow, I've determined that Gnumeric calls
gnm_expr_top_eval() multiple times (probably for the same cell) after I type
my expression. There some iterations occur in the gnm_cell_eval_content() (in
the src/dependent.c). What actually happens there is magic for me, at least
today. Anyway it has no relation to the changes in the gda plugin (I hope so).

So. If the user typed something (not correct initially) in the arguments of
readdbtable()/execsql() functions, and then corrected the same information in
the GDA login dialog (i.e., specified a correct DSN, supplied correct username
and password), he will not receive his data from the database. The changes
in the login dialog are not reflected in the initial cell expression, so even
after first successfull request gnm_expr_top_eval() will call readdbtable()
/execsql() again with the old, spreadsheet-supplied arguments. The useless (in
this case) login dialog will appear some times, and then nothing will happen.

I really do not know how to solve this situation.

If the DSN and login information are initially correct, the login dialog will
appear once, then this data will be cached, and on the following calls to 
gnm_expr_top_eval()->...readdbtable()/execsql(), it will not appear.

Also, when user types the =readdbtable()/=execsql() expression in a cell, then
presses Ctrl+Shift+Enter and cancels the login dialog, the login dialog will
appear again and again then.


Brief patch overview
--------------------
* configure.ac
  Added checks for newer version of libgda and for libgda-ui.

* plugins/gda/plugin-gda.c

  display_recordset()
    - Fixed a memory leak. When array is created and then an error reported,
      array was not detroyed.

  cnc_key_fill()
    - Added a new function that unifies how the CncKey will look for various
      cases. The purpose is to make hash of ("DSN",NULL,NULL) be equal to hash
      of ("DSN","","").
  
  build_gdadsn_auth_info()
    - Just moved the code to a separate function to make open_connectionm less
      bloated

  query_connection_info()
    - Same as above. All UI functions are used here and only here.

  open_connection()
    - Refactored using the changes described above.

  conn_error()
    - Introduced to remove redundancy. Also the error message is now properly
      formatted (it displayed "%s" in the cell before).

  gnumeric_execSQL()
  gnumeric_readDBTable()
    - Modified these functions to use conn_error()

  GnmFuncDescriptor gdaif_functions[]
    - Modified according to the changes in the API.

Dmitry, nice work!
I think that Morten will review the issues you raise. Otherwise, I would say commit.

I am guessing that what you see has to do with checking validations.

We tentatively poke the new contents into a cell, then check validation
constraints (if any), then undo, and then finally do the full entering
of the new contents into the cell.

Not elegant, and not easy to fix.

Go ahead and commit what you have.  Consider adding yourself to dialog-about.c

Committed.

This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.