Re: [Planner Dev] libgda not found trying to build with db support * patch attached *

["lincoln phipps openmutual net" <lincoln phipps openmutual net>]

Richard Hult wrote:

> fre 2004-02-27 klockan 16.02 skrev Kurt Maute:
>
>>On Thu, 2004-02-26 at 15:08, Richard Hult wrote:
>>
>>>tor 2004-02-26 klockan 16.23 skrev Kurt Maute:
>>>
>>>>Is this another setup issue, or is the new gda engine not compatible
>>>>with the old database setup?
>>>
>>>Hm, which version of libgda do you have?
>>>
>>>/Richard
>>>
>>
>>I'm using:
>>libgda-1.0.2-1
>>libgda-devel-1.0.2-1
>
>
> Alvaro, do you know if we are perhaps using something that's not
> available in 1.0.x? If so, maybe we should fix it since 1.1.x is the
> development branch if I recall correctly.
>
> /Richard
>

Richard

The planner-011cvs-lcjp-20040307-gdalibs_makefile.diff
is just the Makefile.am change to fix the GDALIBS stuff
to fix the bug on this email thread.

The other file mentioned,
planner-011cvs-lcjp-20040307-shortname_sql.diff
has ALL changes mentioned below PLUS my task short_name differences
in one large file and is in a separate email. It has the short_name 
feature plus the bugs found in testing.

I got this problem too with the configuration settings. My system
is a recent install for the gda stuff as I'd never used the database
gda things until today.

I found the following and think I've got a fix for the issue that
was mentioned regarding the gda_config_save symbol.

1) (This fixes the error that others have mentioned) The
Makefile.am for the SQL stuff doesn't include the GDA_CFLAGS
as far as I can see so I'm suggesting.....

See attached planner-011cvs-lcjp-20040307-gdalibs_makefile.diff

2) The code creates an odd entry in the .libgda/config
called planner-auto yet also uses planner_project in the code
as well as a unassigned dsn_name (in the mrp_sql_load_project).
Or was this the actual intended behaviour !?

See in libplanner/mrp-sql.c   mrp_sql_save_project ()

-	gchar        *dsn_name = "planner-auto";
+	gchar        *dsn_name = "planner_project";


and in mrp_sql_load_project () the dns_name is used before
being defined. It could be that this code is as expected but
seems odd as it pust junk into .libgda/config

See in libplanner/mrp-sql.c   mrp_sql_load_project ()

-	gchar          *dsn_name;
+	gchar          *dsn_name = "planner_project";

My diff planner-011cvs-lcjp-20040307-shortname_sql.diff
(separate email) has these changes. I can't split them out
as I've done other work in the file and I thus may get lost chunks.

3) The code doesn't check is the provider actually exists before
offering the option to Save/Load etc. Planner only uses a provider
of PostgreSQL (why can't it also use MySQL given its not like we
need much in the way of ACID and the data types in use are not
very complicated.

My system didn't actually have gda-postgres installed initially
and the older gda packages I had installed only had .a files
in /usr/lib/libgda/providers but I eventually got all the right
packages. For the record these are,

# rpm -qa | grep gda
libgda0-0.2.96-10mdk
gda-mysql0-0.2.96-10mdk
libgda0-devel-0.2.96-10mdk
gda2.0-postgres-1.0.3-3mdk
libgda2.0_1-1.0.3-3mdk
libgda2.0_1-devel-1.0.3-3mdk
gda-postgres0-0.2.96-10mdk
gda2.0-1.0.3-3mdk

If you don't have the package that provides
/usr/lib/libgda/providers/gda-postgres.so then you'll
get a message,

Could not find provider PostgreSQL in the current setup

or if you have really messed up your libgda install then
you can get a mesage complaining about a difference
in GdaPostgresProvider abd GdaServerProvider class sizes.
Reinstall libgda/gda/gda-postgres !

4) An incorrect CLOSE of ifcursor in planner-sql-plugin.c
(should be CLOSE mycursor ). See the main patch (separate email)
planner-011cvs-lcjp-20040307-shortname_sql.diff
for fix to this.


5) Other bugs (haven't done bugzillas yet);

- No database maintenance - you can't delete a project.
- Saving a project back onto the database adds a new entry
	but no other identification as to which is which.
- The database load orders resource names differently
	from a file-open (at least on my machine).
- Opening up a project from a file and then changing a resource
	unit for an assignment updates gantt correctly
	but opening up a project from a database and then
	changing a resource unit value for an assignment
	doesn't update the gantt [?] value. It does once you
	change the assignment. My guess is a signal not being
	attached for notify::assignment in the parts that
	build up the project from a database.
- changing an assignment unit value doesn't actually mark
	a project as changed when you do a File Close.

Rgds,
Lincoln.







Index: src/Makefile.am
===================================================================
RCS file: /cvs/gnome/planner/src/Makefile.am,v
retrieving revision 1.8
diff -u -b -B -p -r1.8 Makefile.am
--- src/Makefile.am	25 Jan 2004 11:33:23 -0000	1.8
+++ src/Makefile.am	7 Mar 2004 19:58:32 -0000
@@ -182,6 +182,10 @@ plugindir = $(libdir)/planner/plugins
 
 if HAVE_GDA
 sql_plugin = libsql-plugin.la
+libsql_plugin_la_SOURCES = planner-sql-plugin.c
+libsql_plugin_la_LIBADD =  $(GDA_LIBS)
+libsql_plugin_la_CFLAGS = $(GDA_CFLAGS) 
+libsql_plugin_la_LDFLAGS = -avoid-version -module
 endif
 
 plugin_LTLIBRARIES = \
@@ -191,11 +195,6 @@ plugin_LTLIBRARIES = \
 libhtml_plugin_la_SOURCES = planner-html-plugin.c
 libhtml_plugin_la_LDFLAGS = -avoid-version -module
 
-if HAVE_GDA
-libsql_plugin_la_SOURCES = planner-sql-plugin.c
-libsql_plugin_la_LDFLAGS = -avoid-version -module
-endif
-
 planner-marshal.h: Makefile.am planner-marshal.list
 	(cd $(srcdir) && \
 	@GLIB_GENMARSHAL@ --prefix=planner_marshal planner-marshal.list --header) > xgen-gmh \