Re: [WebERP-developers] SQL & database stuff

[Tim S. <ti...@we...>]

Hi Lindsay,

I did some scripts a while ago that used the php curl extension to
automate webERP from the command line, and then checked each
transaction as it was entered. I think I did a sales order one, but
then I changed the sales order scripts, and the test scripts broke.
This made me think that what I was doing needed generalising,  and I
didn't have the time. I think testing is something that we do urgently
need to improve on.

As for mysql, Oracle have purchased the company that offers commercial
support for the database, but they don't not own the code which
remains under the GPL. I believe some of the developers have already
left that company, and mysql is too firmly entrenched in the market
for oracle to kill it, even if that is what they want to do. Having
said that if you want to support postgres, then that is great.

thanks
Tim


On 29 April 2010 10:03, Lindsay Harris <li...@bl...> wrote:
> On Thursday 29 April 2010 05:48:38 Tim Schofield wrote:
>> Hi Lindsay,
>>
>> On 27 April 2010 13:13, Lindsay Harris <li...@bl...> wrote:
>> > I've been thinking a great deal about installation and upgrades, and SQL
>> > and databases of late.
>> >
>> > Installation
>> > How I would like webERP to handle installation works like this:-
>> > 1/ Dump source code onto web server
>  ...
>> > 7/ Done.
>>
>> This should be what happens now, though it may need some refinement.
>
> Golly!  I did the first fresh install just now for 3+ years!  My usual upgrade
> path is to put code in new directory, copy working config file over, and the
> companies tree, and adjust apache to use the new directory.  [Note that I keep
> my webERP code outside the htdocs directory - it's safer and easier with my
> "content management" system (aka rsync!)].
>
> I did have some problems with the script in 3.11.2 - the companies directory
> not being writeable took a while to figure out, because it was trying to
> verify it could write to weberpdemo/part_pics,  which does not exist.  I'll
> look into how that is in the SVN trunk and adjust accordingly.
>
> It also seems not to have created the DB for the company name I set.  I'll
> repeat and see what happened (user error quite possible).
>
> But otherwise, pretty much exactly what I was thinking!
>>
>> > Upgrade
>
>> > 3/ IF different, require administrator to login, and this will then apply
>> > the upgrade scripts - should handle PHP scripts too, e,g, create new
>> > directories. Upon successful completion, the system is opened to all.
>>
>> I agree, but I'm not sure I agree with forcing the upgrade. Users
>> should have a choice about upgrading.
>>
>> There was a discussion similar to this a while ago, but nothing came of it.
>
> Yes, I remember the discussion and the no conclusion.   As for forcing
> upgrades,  I feel that it is asking for trouble if we have code using one
> database schema,  and a database with a different schema.
>
> One thing I did think about trying was whether the upgrade could be run as a
> transaction, so that a failure would result in no change.  I know next to
> nothing about the restrictions and capabilities of transactions,  but it seems
> like a good idea.
>>
>> > SQL & database
>> > My preference is for a more DB agnostic form of SQL scripts.
>>
>> Personally I need to be convinced about the need to support other
>> databases. I don't believe most accountants will care or even really
>> be aware of the underlying database.
>
> I agree that users of webERP don't care how the data is stored.  The IT
> department might - assuming there is one.
>
>> I think the problem comes down to
>> whether its worth the extra work in checking that any new code works
>> for all the databases. We used to support postgres  but there wasn't
>> the will to maintain the code for both databases.
>
> I did volunteer to support it,  with the proviso that it would not be until my
> house was built.  It is now,  and I even have some time for such things.  At
> least some weeks :-(
>
> I guess my concern is that being restricted to MySQL, which is now owned by
> Oracle IIRC, would leave us with a big problem if MySQL licensing terms were
> to change, for instance.  Being critically dependent (for some definition) on
> that makes me cautious.
>
> I do understand the support/testing issues.  In fact,  testing is another
> whole can of worms,  and I think that too needs to be investigated and even to
> some extent formalised.  That is, test scripts, applications etc.  Google
> turns up many web application testing products.   And the API provides some
> sort of back door into the DB, so that we could have something poke at the web
> interface and then use the API to see what happened to the database contents.
>
> But that is getting into another issue altogether.
>
> Lindsay
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>



-- 
WebERP Africa Ltd
+447710427049
+255784602561
www.weberpafrica.com