[Vtigercrm-developers] Postgres Integration in 4.2.5

[Sergio A. Kessler]

I always write queries like this:

$query = <<<END
    select
        *
    from
        table1,
        table2,
    where
        foo = ?
        and
        zeta = ?
    group by
        tita
    order by
        zeta
END;

it's a very legible format,
HTH,
/sak

On 3/13/06, Allan Bush <allan.bush at gmail.com> wrote:
> Yeah breaking the queries up into multiple lines would be a huge help
> when dealing with diff files and it improves readability (maybe we
> should come up with a query formatting guide to standardize when to
> break a line and how much to indent the next line) .
>
> I'm really busy today and maybe tomorrow but I can merge in a bunch of
> changes after that.
>
> On 3/13/06, Mike Fedyk <mfedyk at mikefedyk.com> wrote:
> > I'll help. :)
> >
> > One thing I'd like to see is better formatted queries.  That would be no
> > more queries that are 300 chars wide, they should be on multiple lines
> > for better maintainability.
> >
> > Comments?
> >
> > Joel Rydbeck wrote:
> >
> > >Jeff / Mike / Allan,
> > >
> > >Thanks for taking the management of branches on Jeff.  I'm behind you on
> > >this one.
> > >
> > >Allan, would you be ready to apply your (rather significant) set of
> > >changes to the branch once its set? --ideally for the last time.
> > >
> > >Once Allan's deltas are in I can go through and finish off any loose
> > >ends.
> > >
> > >I think it's fine if there are a few PG bugs once we re-merge with
> > >mainline --the idea is to clear the branch hurdle.
> > >
> > >Would anyone out there be willing to do a MySQL validation once we have
> > >the PostgreSQL changes into the branch?
> > >
> > >Regards,
> > >
> > >- Joel
> > >
> > >
> > >
> > >-----Original Message-----
> > >From: vtigercrm-developers-bounces at lists.vtigercrm.com
> > >[mailto:vtigercrm-developers-bounces at lists.vtigercrm.com] On Behalf Of
> > >Mike Fedyk
> > >Sent: Monday, March 13, 2006 5:16 PM
> > >To: vtigercrm-developers at lists.vtigercrm.com
> > >Subject: Re: [Vtigercrm-developers] Postgres Integration in 4.2.5
> > >
> > >I like it.
> > >
> > >Go ahead and branch if there are no detractors.
> > >
> > >Mike
> > >
> > >Jeff Kowalczyk wrote:
> > >
> > >
> > >
> > >>Joel Rydbeck wrote:
> > >>
> > >>
> > >>
> > >>
> > >>>Mike / Allan / Jeff,
> > >>>
> > >>>My understanding of the plan for PostgreSQL in the 4.x generation is
> > >>>that there will be a window to accept it into the 4.2.5 release.  What
> > >>>would work best from a timeline for making the changes?
> > >>>
> > >>>
> > >>>
> > >>>
> > >>The original idea was to keep
> > >>vtigercrm/branches/4.2_postgresql_integration short and sweet, so that
> > >>
> > >>
> > >it
> > >
> > >
> > >>could be a good artifact for the same work that must go into
> > >>vtigercrm/trunk before vtigercrm-5.0.0beta1.
> > >>
> > >>I'd like to contribute to postgresql integration testing and bug
> > >>reporting. Knowing there is no foolproof migration route from mysql to
> > >>postgresql, I can't really deploy my first vtigercrm semi-production
> > >>instance on mysql.
> > >>
> > >>I propose the following:
> > >>
> > >>- Lets make vtigercrm/branches/4.2_postgresql_integration from
> > >>vtigercrm/branches/4.2 as soon as the integrators are ready to start
> > >>committing. Word from a few of the parties that they're ready is enough
> > >>assent, IMO.
> > >>
> > >>- I'll volunteer to keep vtigercrm/branches/4.2_postgresql_integration
> > >>
> > >>
> > >in
> > >
> > >
> > >>sync with late changes to vtigercrm/branches/4.2 leading up to
> > >>vtigercrm/tags/vtigercrm-4.2.4. They should be few anyway, so the
> > >>
> > >>
> > >purity
> > >
> > >
> > >>of branching only after vtigercrm/tags/vtigercrm-4.2.4 is outweighed by
> > >>the practicality of getting the integration started now. Change
> > >>
> > >>
> > >velocity
> > >
> > >
> > >>on vtigercrm/branches/4.2 is likely at its lowest ebb during -rcX
> > >>
> > >>
> > >status.
> > >
> > >
> > >>- As soon as vtigercrm/branches/4.2_postgresql_integration can
> > >>
> > >>
> > >bootstrap
> > >
> > >
> > >>into postgresql and load prepared datasets (like the sample dataset), I
> > >>and a presumed whole bunch of other people will be testing its
> > >>functionality. I'll try to organize and verify the trouble reports into
> > >>trac tickets that the integrators can act upon.
> > >>
> > >>Thoughts?
> > >>
> > >>_______________________________________________