Hi! > > 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 !? > > Alvaro did the GDA conversion, he should know :) > Hmm, in GDA world you need to create DSN to access to the database. Currently, we create the DSN in the program and don't use already created DSN. For load/save the idea was to use the same DSN params but, I am not sure how, the load project doesn't have a assigned dns_name. I will send a patch to solve it and also, not to use "planner test" as the description text and better use "planner project". About the DSN "planner_project" it is created in the frontend, and it is used to search for actual projects in the database. Later, when you select one to load, we use in the backed "planner_auto" as the DSN. I think it is a good idea to rename "planner_project" to "planner-auto" also. The name "planner-auto" was selected to show that this is an auto DSN created in the code. > > 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. > > That's OK. Just let me know when you are ready for a patch review. > > > 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. > Yes, the GDA code needs more love. I have tried to convert from libpq to libgda not doing any regression and now, it is time to work in the code to make things like checking for providers, adding new databases (this is why we have changed to libgda) and others things. > Supporting mysql as a provider is certainly on the todo, just waiting > for someone to do it. > > > 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. > > Good catch! > > > 5) Other bugs (haven't done bugzillas yet); > > > > - No database maintenance - you can't delete a project. Yes, you can't do it with the libpq backend, this is a new feature for the gda backend that needs to be done. > > - Saving a project back onto the database adds a new entry > > but no other identification as to which is which. > > This sounds like a regression from the gda conversion... > This is the kind of things I have in mind when I did the conversion. Not to have any regression. I will test this prob this afternoon. > > - 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. I think there are some problems with saving custom calendars. Maybe the best thing could be to add an entry to bugzilla with all this things. > > The two last sound like the same bug. > > So, about the patches, do you still want me to hold committing them > until you have the complete set done, or should I go ahead and commit > the makefile fix, for example? > > Thanks for you awesome work! Yes lincoln, thanks for catching up this bugs. Do you plan to work on things like database maintenance? Cheers > Richard
Attachment:
signature.asc
Description: Esta parte del mensaje =?ISO-8859-1?Q?est=E1?= firmada digitalmente