> Hi Charlie,
>
> at first, the coWiki project got new maintainers. I am not the main person
> to talk to, although I kept a bit techincal influence :) But for this
> problem I am the right one anyway :)
>
> You may use one of the mailinlists listed on
> <http://cowiki.tigris.org/servlets/ProjectMailingListList>. I'll CC this
> reply to one of these lists.
I see. In fact, I am a subscriber to all of the four lists(if there
aren't any new ones), because of my high interest and intention in
contributing to cowiki.
>
> There a few possible solutions for the UNIX_TIMESTAMP problem:
>
> * either the DAOs use a different function conditionally or
> * a stored procedure for Postgres named UNIX_TIMESTAMP will do the job (
> this best solution, and I think, we have something like this already. Wedro?)
>
> For the CONV() problem a stored procedure could the work too.
>
Yes, that was my first thought. I did created the UNIX_TIMESTAMP
procedure and it worked, although I don't think it is the best way to
do...Well, it doesn't matter unless someone could find out better
solutions.
> Wedro, one of the (weak) contributors claims that he has the code for
> Postgres abstraction too ... Maybe you talk with each other. His address is
> <wedro-jqHnx1hy4Dsdnm+yROfE0A@xxxxxxxxxxxxxxxx>, or you can reach him via our
> other lists I mentioned
> above.
OK. I'll contact Wedro, perhaps after the jobs you mentioned below are
done. That might be a better point. The reason will be stated later.
>
> > I also noticed there are comments at the use conv(), so I think you
> > are planning to support many DBMS's, rather than just mysql.
> > Is that correct?
>
> Yes. A BIG BUT at this point: please do not change the existing DAOs _yet_.
> The problem here is, that they do not support ACID transactions, and we are
> currently going to migrate from MySQL MyISAM tables to InnoDB, which support
> transactions.
Oops...I think I already did...and not so few changes were made. But
in the case you've done good abstraction, it won't be a problem. If I
am to help in the job, I'll do it when you think it's time.
>
> Hence there will be changes in the abstraction classes
> (dao/class.Storage*.php), that are required for the task _and_ changes in
> the DAOs to make InnoDB and Postgres work properly.
>
> At this time I am woking on a installer, that should help us in the future
> to migrate old installation from MyISAM to InnoDB etc.
>
> If this installer is finished, I want to rewrite the DAOs with commit() and
> rollback() functionalities. Then _and_ only _then_, it makes sense to adjust
> the code for Postgres.
>
> > If it is, then how should I deal with them, or what should I
> > do to help?
>
> I would suggest to wait with this Postgres thing for two/three weeks and
> maybe take a look at something else what is interesting for you in coWiki.
>
> > Actually, I believe I've done most of the job porting cowiki to
> > postgresql, except, of course, those features available only in mysql.
>
> Hopefully you didn't to much, as we would work against each others then :)
>
Never mind, it's just a good practice for me(mostly on Postgres) :)
And I knew it at the very first, because I never think a 0.3.4 version
is quite stable a release. cowiki is still in its early development
stage, isn't it?
> regards dtg
--
Regards, Charlie
|