<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head><meta content="text/html;charset=UTF-8" http-equiv="Content-Type"></head><body >Hi!
<br>
<br>I would suggest that we have a branch for the PostGres part so that the merging will be a separate operation.
<br>This will ensure that we are able to keep track of breakages as well.
<br>
<br>JeffK, what do you suggest?
<br>
<br>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.
<br>
<br>Allan, no offence meant. Just voicing my concern.
<br>
<br>Richie<br><br><br><br><br>---- Allan Bush<allan.bush+vtiger_dev@gmail.com> wrote ---- <br><br><blockquote style='border-left: 2px solid #0000FF; padding: 6px;'><html>
<xbody>
Filling in the gaps.<br><br>On 5/3/06, Joel Rydbeck <Joel.Rydbeck@nubrek.com> wrote:<br>> Richie,<br>><br>> I'll let Allan and Jeff fill in the gaps.<br>><br>> a) How do we give the user the option of using PostGres while installation?<br>><br>> 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.<br>><br>> b) What will be the impact if any on the mysql compatible queries that we have now? Will the current queries be changed?<br><br>The current queries will be changed, the changes should have no effect<br>on the mysql compatibility. I didn't encounter any mysql regression<br>bugs doing the changes for 4.2 and I don't expect any for 5.0.<br><br>><br>> 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?<br>><br>> 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.<br>><br>> d) How are we going to handle simultaneous development on the core code? How to handle breakages if any?<br>><br>> 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).<br><br>The same way you currently handle simultaneous development between the<br>multiple contributers. I don't anticipate much breakage, the largest<br>changeset will probably be done in one commit during the first day I<br>work on this to get the installer working for both database types. As<br>I work pretty much opposite hours from the rest of the team conflicts<br>should be rare.<br><br>><br>> Thank you for your support and assistance in performing this.<br>><br>> Regards,<br>><br>> - Joel<br>><br><br>I just want to bring one point up which may ease you mind a little.<br><br>SQL is a standard much like HTML. MySQL is like the IE of databases<br>well Postgres is closer to a Firefox, in the sense that MySQL will<br>make the best of any crap you send it well Postgres follows the<br>standards more closely. So what I'm going to be doing is basically<br>standardizing the SQL, and unlike IE MySQL supports the standards<br>properly (well it's laking several features and just ignores some<br>stuff but since I'm not adding anything that won't be a problem).<br><br>Allan<br><br>_______________________________________________<br>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! <a href="http://zohoplanner.com/?vt">http://zohoplanner.com/?vt</a> <br>
</xbody>
</html></blockquote></body></html>