[Vtigercrm-developers] postgres support in v5

[Allan Bush]

Fair enough.

My concern is that if we branch someone will move a bunch of files
around or refactor some code again and we'll have problems/be unable
to merge, and it would end up being the 3rd time I've tried to add
postgres support only to have it not be taken up.

Also I don't think the correct software development practice is to
make a branch here.  Branches should be made when a release is nearing
to allow aggressive development to continue or if a feature is going
to introduced prolonged breakage, neither of which I see happening
here.  Changesets are for managing bugs introduced by coding changes.

That said I have no problems branching if Jeff wants to handle keeping
everything in sync.

On 5/3/06, Richie <richie at vtiger.com> wrote:
> Hi!
>
> I would suggest that we have a branch for the PostGres part so that the
> merging will be a separate operation.
> This will ensure that we are able to keep track of breakages as well.
>
> JeffK, what do you suggest?
>
> The core-team has been working on bug-fixes and has done quite a lot of
> changes. I am concerned that we might again have to run in circles in the
> worst case with the PostGres fixes.
>
> Allan, no offence meant. Just voicing my concern.
>
> Richie
>
>
>
>
> ---- Allan Bush<allan.bush+vtiger_dev at gmail.com> wrote ----
>
>
>  Filling in the gaps.
>
> On 5/3/06, Joel Rydbeck <Joel.Rydbeck at nubrek.com> wrote:
> > Richie,
> >
> > I'll let Allan and Jeff fill in the gaps.
> >
> > a) How do we give the user the option of using PostGres while
> installation?
> >
> > This would be at installation point, we'll provide it in the dropdown on
> step 1 or step 2 (whichever one the user configures the db in). I started
> working on this one last night.
> >
> > b) What will be the impact if any on the mysql compatible queries that we
> have now? Will the current queries be changed?
>
> The current queries will be changed, the changes should have no effect
> on the mysql compatibility. I didn't encounter any mysql regression
> bugs doing the changes for 4.2 and I don't expect any for 5.0.
>
> >
> > c) If the current queries are changed as such they may affect the core
> team's development. Are we going to go on putting an IF check for PostGres?
> >
> > I would expect that the same queries will work for both databases, in the
> case of incompatible queries, my vote would be an if/else for the short
> term. Long-term, ADODB provides some healthy extensibility and abstraction
> of the db layer. My vote is that we get PGSQL support in now, and then
> polish with ADODB as we go along.
> >
> > d) How are we going to handle simultaneous development on the core code?
> How to handle breakages if any?
> >
> > Allan will likely be doing the bulk of the commits, so I'll let him
> address this. My commits will likely be isolated to one page at a time. If
> you guys are able to validate our work in MySQL as we go along, that would
> be very helpful. I'll try to test it at the same time (good ol' config.php
> swap).
>
> The same way you currently handle simultaneous development between the
> multiple contributers. I don't anticipate much breakage, the largest
> changeset will probably be done in one commit during the first day I
> work on this to get the installer working for both database types. As
> I work pretty much opposite hours from the rest of the team conflicts
> should be rare.
>
> >
> > Thank you for your support and assistance in performing this.
> >
> > Regards,
> >
> > - Joel
> >
>
> I just want to bring one point up which may ease you mind a little.
>
> SQL is a standard much like HTML. MySQL is like the IE of databases
> well Postgres is closer to a Firefox, in the sense that MySQL will
> make the best of any crap you send it well Postgres follows the
> standards more closely. So what I'm going to be doing is basically
> standardizing the SQL, and unlike IE MySQL supports the standards
> properly (well it's laking several features and just ignores some
> stuff but since I'm not adding anything that won't be a problem).
>
> Allan
>
> _______________________________________________
> This vtiger.com email is sponsored by Zoho Planner. Still scribbling down
> your To-Do's on bits of paper & palms of your hands? Try the AJAX enabled,
> personal organizer online, Zoho Planner for FREE instead!
> http://zohoplanner.com/?vt
>
>
> _______________________________________________
> This vtiger.com email is sponsored by Zoho Planner. Still scribbling down
> your To-Do's on bits of paper & palms of your hands? Try the AJAX enabled,
> personal organizer online, Zoho Planner for FREE instead!
> http://zohoplanner.com/?vt
>
>