Re: [gnome-db] PATCH: gda_postgres_remove_row.

[Vivien Malerba <vmalerba gmail com>]

On Thu, 20 Jan 2005 20:27:54 +1000, Bas Driessen <bas driessen xobas com> wrote:
> On Thu, 2005-01-20 at 10:51 +0100, Vivien Malerba wrote:
> > On Thu, 20 Jan 2005 19:32:45 +1000, Bas Driessen <bas driessen xobas com> wrote:
> > > On Thu, 2005-01-20 at 10:11 +0100, Vivien Malerba wrote:
> > > > On Wed, 19 Jan 2005 20:23:00 +1000, Bas Driessen <bas driessen xobas com> wrote:
> > > > >  Hello,
> > > > >
> > > > >  Attached a patch for the remove_row method for Postgres. I made changes in
> > > > > 2 areas:
> > > > >
> > > > >  -1 data_model_hash implementation. In order to keep track of rows removed,
> > > > > I introduced an array to keep track of the active rows in a data model. The
> > > > > beauty of this is, that removed rows now physically do not show up in the
> > > > > data model. So all rows after the removed row will be renumbered without
> > > > > loosing their link with the original source like the Postgres cursor for
> > > > > instance.
> > > > >
> > > > >  -2 postgres recordset implementation. Added the remove_row functionality
> > > > > (among other changes see ChangeLog for that).
> > > > >
> > > > >  Attached patches for both head as 1.2. Please review. I have hit it very
> > > > > hard and so far I could not break it.  If patch is approved, all Postgres
> > > > > users should test against the latest cvs to find out if they run in any
> > > > > problems. If so, let me know the issue(s). I will continue testing in the
> > > > > next couple of days.
> > > > >
> > > >
> > > > I have patched my own version of libgda HEAD with that patch (and with
> > > > the new one: guess_table_name) and I can commit them to HEAD if you
> > > > want. We can wait a bit longer before commiting them to 1.2 branch if
> > > > you want to do some more testing (I don't have time to do some
> > > > myself).
> > >
> > > Great, thanks for response and review Vivien. Yes, please go ahead and
> > > commit to HEAD. Did some more testing today and am confident that the
> > > changes are OK and nothing is broken. Therefore it should be safe to
> > > commit to the 1.2 branch as well. This new functionality is important in
> > > my projects, so in case there are some issues, I will correct them
> > > immediately. Thanks again for your help.
> > >
> > >
> >
> >
> > Ok, I'll let Rodrigo decide for the 1.2 branch and I'll do the commit
> > for the HDEA branch ASAP (this WE propably).
> 
> Regarding the 1.2 branch. The only reason I keep asking for my changes
> to go into the 1.2 branch, is that I assume that a 1.2.1 release will be
> cut way earlier than a release containing HEAD (2.0.0 ?? ) If however
> you will start a similar release cycle as you did with 1.0.x vs 1.1.x
> where there will be a release in the not to distant future, then I am
> happy to go with that. So if possible, can you please give some estimate
> release dates of the new 1.2.x vs 2.0.x (or 1.3.x) road map?
> 
> For me (and for everybody I assume) it is so much easier to build and
> release a software package around an official libgda release rather than
> an own composition.
> 

It's difficult to predict the road map for 2.0.x (or 1.3.x) as there
will be many changes: a few in libgda and many in libgnomedb. I'd say
that we'll have a clearer view when I finally commit all the changes
I'm working on libgnomedb (I've added around 70000 lines of code from
the libmergeant library), which should be soon.

For the 1.2.x releases, Rodrigo can answer better than me as I don't
know what he plans to do. Still I think Rodrigo can commit your
patches to the 1.2 so they can be tested. Rodrigo?

The important thing is that you keep making the patches for both the
1.2 and HEAD branches to avoid having too much work to catch up later
in HEAD.

Vivien