MySQL question

MySQL question



That's what I refering to "not ready for MySQL". My client specifically
asked about MySQL.

Many thanks,
Leslie


> Dear Leslie,
>
> No, I think MM5 is ready but....the documentation to support Third
> Party
> Modules and Third Party Modules themselves are not ready for MySQL.
>
> Thank you,
>
> Nerd Boy
>
> 1-573-292-1136
> <A HREF ="http://www.nerdboyinc.com">http://www.nerdboyinc.com</A>
> <A HREF ="http://www.doyoureallycare.com">http://www.doyoureallycare.com</A>
> <A HREF ="http://www.nbicentral.com">http://www.nbicentral.com</A>
> <A HREF ="http://www.crosstowntraffic.net">http://www.crosstowntraffic.net</A>
> Your alternative source for Miva Merchant Modules
>
> For Customer Service and Support:
> <A HREF ="http://www.nbisupport.com">http://www.nbisupport.com</A>
> or send email to: [email protected]
>
> <A HREF ="http://www.nerdboyproductions.com">http://www.nerdboyproductions.com</A>
> <A HREF ="http://www.asmallurl.com">http://www.asmallurl.com</A>
> <A HREF ="http://www.nbiracing.com">http://www.nbiracing.com</A>
> <A HREF ="http://www.yourlottosite.com">http://www.yourlottosite.com</A>
>

>
>
>> So the bottom line is ... MM5 is not quite ready for MySQL?
>>
>> Leslie
>>
>>
>>> In most scenarios, the MM5 would not need the load balancing across
>>> multiple servers, so the issue would not come up. But when a store
>>> decides it wants that load balancing, there will be database issues
>>> along
>>> with the issue of needing mirror scripts copies of the modules.
>>> Updating
>>> module versions (3rd party and miva core) will be a headache. It is
>>> one
>>> thing for the host to unzip multiple copies of core mvc files, but what
>>> about the new update wizard. It is going to flow the new module
>>> versions
>>> to one location. So you will have one server updated with new scripts
>>> and
>>> others not. It definitely is going to require some sort of technique
>>> to
>>> put all scripts on the single server. If that is done, then it might
>>> not
>>> be an issue with the data either. This is going to be a trial and
>>> error
>>> experimentation. I would hope that hosts share their knowledge rather
>>> than "trade secret" these issues. Film at 11.
>>>
>>>
>>> --
>>> Bill Weiland - Emporium Plus <A HREF ="http://www.emporiumplus.com/store.mvc">http://www.emporiumplus.com/store.mvc</A>
>>> Modules for eCommerce. Mail Mgr, Coupon, Rate This, Wait List Mgr,
>>> PayPal, Gift/Wish List, Froogle data feed, Shipping & dozens more
>>> Online Documentation <A HREF ="http://www.emporiumplus.com/tk3/v3/doc.htm">http://www.emporiumplus.com/tk3/v3/doc.htm</A>
>>> Question <A HREF ="http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=SPTS">http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=SPTS</A>
>>> |
>>>
>>> ---- David Hubbard <[email protected]> wrote:
>>>> From: William Weiland
>>>> >
>>>> > The modules within merchant were written that way because
>>>> > they have had a year or two to write them. You know how
>>>> > long we have had since Miva settled on how and where the
>>>> > data would be located and files named. So the suggested
>>>> > first step was to use the old access method for your
>>>
>>>> > module's own configuration and concentrate on the mivasql methods
>>>> for
>>>> > accessing store data (products/cats/orders/etc). The next step,
>>>> which
>>>> > will take considerable time if the module has a lot of configuration
>>>> > databases, will be to convert the module's internal data to mivasql
>>>> > calls.
>>>>
>>>> Ah, I didn't realize that was even an option. That
>>>> definitely would raise some issues with load balancing;
>>>> those considering it would need to ensure that the
>>>> modules they are using have been written using the
>>>> SQL method so no surprises result.
>>>>
>>>> David
>>>>

MySQL question



I think all of the issues can be worked out, but if the client insists on the load balancing, then that may be a stumbling block for updates of core modules and 3rd party modules which are not using the mysql queries for their internal data. Then it would only be a problem if the internal data is dynamic. If it is a configuration data of the module's screen, etc, that can be set once and the data mirrored across servers.

--
Bill Weiland - Emporium Plus <A HREF ="http://www.emporiumplus.com/store.mvc ">http://www.emporiumplus.com/store.mvc </A>
Modules for eCommerce. Mail Mgr, Coupon, Rate This, Wait List Mgr,
PayPal, Gift/Wish List, Froogle data feed, Shipping & dozens more
Online Documentation <A HREF ="http://www.emporiumplus.com/tk3/v3/doc.htm ">http://www.emporiumplus.com/tk3/v3/doc.htm </A>
Question <A HREF ="http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=SPTS ">http://www.emporiumplus.com/mivamodu...vc?Screen=SPTS </A>
|

---- Leslie Nord - Webs Your Way <[email protected]> wrote:
> That's what I refering to "not ready for MySQL". My client specifically
> asked about MySQL.
>
> Many thanks,
> Leslie
>
>
> > Dear Leslie,
> >
> > No, I think MM5 is ready but....the documentation to support Third
> > Party
> > Modules and Third Party Modules themselves are not ready for MySQL.
> >
> > Thank you,
> >
> > Nerd Boy
> >
> > 1-573-292-1136
> > <A HREF ="http://www.nerdboyinc.com">http://www.nerdboyinc.com</A>
> > <A HREF ="http://www.doyoureallycare.com">http://www.doyoureallycare.com</A>
> > <A HREF ="http://www.nbicentral.com">http://www.nbicentral.com</A>
> > <A HREF ="http://www.crosstowntraffic.net">http://www.crosstowntraffic.net</A>
> > Your alternative source for Miva Merchant Modules
> >
> > For Customer Service and Support:
> > <A HREF ="http://www.nbisupport.com">http://www.nbisupport.com</A>
> > or send email to: [email protected]
> >
> > <A HREF ="http://www.nerdboyproductions.com">http://www.nerdboyproductions.com</A>
> > <A HREF ="http://www.asmallurl.com">http://www.asmallurl.com</A>
> > <A HREF ="http://www.nbiracing.com">http://www.nbiracing.com</A>
> > <A HREF ="http://www.yourlottosite.com">http://www.yourlottosite.com</A>
> >
>
> >
> >
> >> So the bottom line is ... MM5 is not quite ready for MySQL?
> >>
> >> Leslie
> >>
> >>
> >>> In most scenarios, the MM5 would not need the load balancing across
> >>> multiple servers, so the issue would not come up. But when a store
> >>> decides it wants that load balancing, there will be database issues
> >>> along
> >>> with the issue of needing mirror scripts copies of the modules.
> >>> Updating
> >>> module versions (3rd party and miva core) will be a headache. It is
> >>> one
> >>> thing for the host to unzip multiple copies of core mvc files, but what
> >>> about the new update wizard. It is going to flow the new module
> >>> versions
> >>> to one location. So you will have one server updated with new scripts
> >>> and
> >>> others not. It definitely is going to require some sort of technique
> >>> to
> >>> put all scripts on the single server. If that is done, then it might
> >>> not
> >>> be an issue with the data either. This is going to be a trial and
> >>> error
> >>> experimentation. I would hope that hosts share their knowledge rather
> >>> than "trade secret" these issues. Film at 11.
> >>>
> >>>
> >>> --
> >>> Bill Weiland - Emporium Plus <A HREF ="http://www.emporiumplus.com/store.mvc">http://www.emporiumplus.com/store.mvc</A>
> >>> Modules for eCommerce. Mail Mgr, Coupon, Rate This, Wait List Mgr,
> >>> PayPal, Gift/Wish List, Froogle data feed, Shipping & dozens more
> >>> Online Documentation <A HREF ="http://www.emporiumplus.com/tk3/v3/doc.htm">http://www.emporiumplus.com/tk3/v3/doc.htm</A>
> >>> Question <A HREF ="http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=SPTS">http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=SPTS</A>
> >>> |
> >>>
> >>> ---- David Hubbard <[email protected]> wrote:
> >>>> From: William Weiland
> >>>> >
> >>>> > The modules within merchant were written that way because
> >>>> > they have had a year or two to write them. You know how
> >>>> > long we have had since Miva settled on how and where the
> >>>> > data would be located and files named. So the suggested
> >>>> > first step was to use the old access method for your
> >>>
> >>>> > module's own configuration and concentrate on the mivasql methods
> >>>> for
> >>>> > accessing store data (products/cats/orders/etc). The next step,
> >>>> which
> >>>> > will take considerable time if the module has a lot of configuration
> >>>> > databases, will be to convert the module's internal data to mivasql
> >>>> > calls.
> >>>>
> >>>> Ah, I didn't realize that was even an option. That
> >>>> definitely would raise some issues with load balancing;
> >>>> those considering it would need to ensure that the
> >>>> modules they are using have been written using the
> >>>> SQL method so no surprises result.
> >>>>
> >>>> David
> >>>>
>
>
>
>

MySQL question



Bill:

Load balancing aside, which most stores
will not need to do, are there any other
issues you see with using MySQL and
third party modules?



Jen
Hostasaurus.Com
Miva Premier Hosting Partner
813.971.8772
[email protected]


-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of William
Weiland
Sent: Thursday, May 05, 2005 9:29 AM
To: [email protected]
Subject: Re: [m5u] MySQL question


I think all of the issues can be worked out, but if the client insists
on the load balancing, then that may be a stumbling block for updates of
core modules and 3rd party modules which are not using the mysql queries
for their internal data. Then it would only be a problem if the
internal data is dynamic. If it is a configuration data of the module's
screen, etc, that can be set once and the data mirrored across servers.


--=20
Bill Weiland - Emporium Plus <A HREF ="http://www.emporiumplus.com/store.mvc=20">http://www.emporiumplus.com/store.mvc=20</A>
Modules for eCommerce. Mail Mgr, Coupon, Rate This, Wait List Mgr,=20
PayPal, Gift/Wish List, Froogle data feed, Shipping & dozens more
Online Documentation <A HREF ="http://www.emporiumplus.com/tk3/v3/doc.htm=20">http://www.emporiumplus.com/tk3/v3/doc.htm=20</A>
Question <A HREF ="http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=3DSPTS =20">http://www.emporiumplus.com/mivamodu...?Screen=3DSPTS =20</A>
|
=20
---- Leslie Nord - Webs Your Way <[email protected]> wrote:=20
> That's what I refering to "not ready for MySQL". My client
specifically
> asked about MySQL.
>=20
> Many thanks,
> Leslie
>=20
>=20
> > Dear Leslie,
> >
> > No, I think MM5 is ready but....the documentation to support
Third
> > Party
> > Modules and Third Party Modules themselves are not ready for MySQL.
> >
> > Thank you,
> >
> > Nerd Boy
> >
> > 1-573-292-1136
> > <A HREF ="http://www.nerdboyinc.com">http://www.nerdboyinc.com</A>
> > <A HREF ="http://www.doyoureallycare.com">http://www.doyoureallycare.com</A>
> > <A HREF ="http://www.nbicentral.com">http://www.nbicentral.com</A>
> > <A HREF ="http://www.crosstowntraffic.net">http://www.crosstowntraffic.net</A>
> > Your alternative source for Miva Merchant Modules
> >
> > For Customer Service and Support:
> > <A HREF ="http://www.nbisupport.com">http://www.nbisupport.com</A>
> > or send email to: [email protected]
> >
> > <A HREF ="http://www.nerdboyproductions.com">http://www.nerdboyproductions.com</A>
> > <A HREF ="http://www.asmallurl.com">http://www.asmallurl.com</A>
> > <A HREF ="http://www.nbiracing.com">http://www.nbiracing.com</A>
> > <A HREF ="http://www.yourlottosite.com">http://www.yourlottosite.com</A>
> >
>=20
> >
> >
> >> So the bottom line is ... MM5 is not quite ready for MySQL?
> >>
> >> Leslie
> >>
> >>
> >>> In most scenarios, the MM5 would not need the load balancing
across
> >>> multiple servers, so the issue would not come up. But when a
store
> >>> decides it wants that load balancing, there will be database
issues
> >>> along
> >>> with the issue of needing mirror scripts copies of the modules.
> >>> Updating
> >>> module versions (3rd party and miva core) will be a headache. It
is
> >>> one
> >>> thing for the host to unzip multiple copies of core mvc files, but
what
> >>> about the new update wizard. It is going to flow the new module
> >>> versions
> >>> to one location. So you will have one server updated with new
scripts
> >>> and
> >>> others not. It definitely is going to require some sort of
technique
> >>> to
> >>> put all scripts on the single server. If that is done, then it
might
> >>> not
> >>> be an issue with the data either. This is going to be a trial and
> >>> error
> >>> experimentation. I would hope that hosts share their knowledge
rather
> >>> than "trade secret" these issues. Film at 11.
> >>>
> >>>
> >>> --
> >>> Bill Weiland - Emporium Plus <A HREF ="http://www.emporiumplus.com/store.mvc">http://www.emporiumplus.com/store.mvc</A>
> >>> Modules for eCommerce. Mail Mgr, Coupon, Rate This, Wait List Mgr,
> >>> PayPal, Gift/Wish List, Froogle data feed, Shipping & dozens more
> >>> Online Documentation <A HREF ="http://www.emporiumplus.com/tk3/v3/doc.htm">http://www.emporiumplus.com/tk3/v3/doc.htm</A>
> >>> Question
<A HREF ="http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=3DSPTS">http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=3DSPTS</A>
> >>> |
> >>>
> >>> ---- David Hubbard <[email protected]> wrote:
> >>>> From: William Weiland
> >>>> >
> >>>> > The modules within merchant were written that way because
> >>>> > they have had a year or two to write them. You know how
> >>>> > long we have had since Miva settled on how and where the
> >>>> > data would be located and files named. So the suggested
> >>>> > first step was to use the old access method for your
> >>>
> >>>> > module's own configuration and concentrate on the mivasql
methods
> >>>> for
> >>>> > accessing store data (products/cats/orders/etc). The next
step,
> >>>> which
> >>>> > will take considerable time if the module has a lot of
configuration
> >>>> > databases, will be to convert the module's internal data to
mivasql
> >>>> > calls.
> >>>>
> >>>> Ah, I didn't realize that was even an option. That
> >>>> definitely would raise some issues with load balancing;
> >>>> those considering it would need to ensure that the
> >>>> modules they are using have been written using the
> >>>> SQL method so no surprises result.
> >>>>
> >>>> David
> >>>>
>=20
>=20
>=20
>=20

MySQL question



From: Leslie Nord - Webs Your Way
>=20
> That's what I refering to "not ready for MySQL". My client=20
> specifically asked about MySQL.

Your client will be safe to go with mm5/mysql regardless,
but what they'll need to watch out for is if they're going
to the mysql version to gain access to the data, they may
not be able to get at the data they want in mysql if the
data they want is that of a third party module that is
not written to use SQL yet. They're not load balancing so
all other issues won't be a factor.

David

MySQL question



From: William Weiland
>=20
> In most scenarios, the MM5 would not need the load balancing=20
> across multiple servers, so the issue would not come up. But=20
> when a store decides it wants that load balancing, there will=20
> be database issues along with the issue of needing mirror=20
> scripts copies of the modules. Updating module versions (3rd=20
> party and miva core) will be a headache. It is one thing for=20
> the host to unzip multiple copies of core mvc files, but what=20
> about the new update wizard. It is going to flow the new=20
> module versions to one location. So you will have one server=20
> updated with new scripts and others not. It definitely is=20
> going to require some sort of technique to put all scripts on=20
> the single server. If that is done, then it might not be an=20
> issue with the data either. This is going to be a trial and=20
> error experimentation. I would hope that hosts share their=20
> knowledge rather than "trade secret" these issues. Film at 11.

There won't be any real trade secret, load balancing is
easy if you do it via hardware; we have redundant Foundry
ServerIron load balancers for customers who do this. Software
load balancing is where it gets kind of ugly. Basically it
would work like this:

1) Client's site points at an IP that exists on the load
balancers.

2) Load balancer sends the request in to one of the real
web servers.

3) The real web servers are using some type of shared
storage for the /mm5 script directory at the very
least; options include NFS, SAN, even Windows file
shares if the web servers are Windows. There won't be
a performance hit by having the scripts on shared storage
because the operating system is going to cache the
files anyway and the script files don't involve a lot of
I/O

4) Empresa, on any of the servers, hits the one back-end
MySQL server for its queries and returns the appropriate
data to the load balancer which sends it on to the client.

So you can run a MM5 update, install a mod, or whatever
else even when load balanced because it will be modifying
the same back-end data and writing the script file to
the shared storage so all servers have the new files
at the same time.

David

MySQL question



There should not be any other issues. The 3rd party modules are accessing the store data using the mivasql/mysql commands. The module's internal data, even if using xbase3 dbfs, can be accessed with the xbase commands because they are and will always (for the foreseeable future) be available in the VM. Load balancing would be the tricky issue for xbase3 commands.

--
Bill Weiland - Emporium Plus <A HREF ="http://www.emporiumplus.com/store.mvc ">http://www.emporiumplus.com/store.mvc </A>
Modules for eCommerce. Mail Mgr, Coupon, Rate This, Wait List Mgr,
PayPal, Gift/Wish List, Froogle data feed, Shipping & dozens more
Online Documentation <A HREF ="http://www.emporiumplus.com/tk3/v3/doc.htm ">http://www.emporiumplus.com/tk3/v3/doc.htm </A>
Question <A HREF ="http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=SPTS ">http://www.emporiumplus.com/mivamodu...vc?Screen=SPTS </A>
|

---- Jen Ferraz <[email protected]> wrote:
> Bill:
>
> Load balancing aside, which most stores
> will not need to do, are there any other
> issues you see with using MySQL and
> third party modules?
>
>
>
> Jen
> Hostasaurus.Com
> Miva Premier Hosting Partner
> 813.971.8772
> [email protected]
>
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of William
> Weiland
> Sent: Thursday, May 05, 2005 9:29 AM
> To: [email protected]
> Subject: Re: [m5u] MySQL question
>
>
> I think all of the issues can be worked out, but if the client insists
> on the load balancing, then that may be a stumbling block for updates of
> core modules and 3rd party modules which are not using the mysql queries
> for their internal data. Then it would only be a problem if the
> internal data is dynamic. If it is a configuration data of the module's
> screen, etc, that can be set once and the data mirrored across servers.
>
>
> --
> Bill Weiland - Emporium Plus <A HREF ="http://www.emporiumplus.com/store.mvc ">http://www.emporiumplus.com/store.mvc </A>
> Modules for eCommerce. Mail Mgr, Coupon, Rate This, Wait List Mgr,
> PayPal, Gift/Wish List, Froogle data feed, Shipping & dozens more
> Online Documentation <A HREF ="http://www.emporiumplus.com/tk3/v3/doc.htm ">http://www.emporiumplus.com/tk3/v3/doc.htm </A>
> Question <A HREF ="http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=SPTS ">http://www.emporiumplus.com/mivamodu...vc?Screen=SPTS </A>
> |
>
> ---- Leslie Nord - Webs Your Way <[email protected]> wrote:
> > That's what I refering to "not ready for MySQL". My client
> specifically
> > asked about MySQL.
> >
> > Many thanks,
> > Leslie
> >
> >
> > > Dear Leslie,
> > >
> > > No, I think MM5 is ready but....the documentation to support
> Third
> > > Party
> > > Modules and Third Party Modules themselves are not ready for MySQL.
> > >
> > > Thank you,
> > >
> > > Nerd Boy
> > >
> > > 1-573-292-1136
> > > <A HREF ="http://www.nerdboyinc.com">http://www.nerdboyinc.com</A>
> > > <A HREF ="http://www.doyoureallycare.com">http://www.doyoureallycare.com</A>
> > > <A HREF ="http://www.nbicentral.com">http://www.nbicentral.com</A>
> > > <A HREF ="http://www.crosstowntraffic.net">http://www.crosstowntraffic.net</A>
> > > Your alternative source for Miva Merchant Modules
> > >
> > > For Customer Service and Support:
> > > <A HREF ="http://www.nbisupport.com">http://www.nbisupport.com</A>
> > > or send email to: [email protected]
> > >
> > > <A HREF ="http://www.nerdboyproductions.com">http://www.nerdboyproductions.com</A>
> > > <A HREF ="http://www.asmallurl.com">http://www.asmallurl.com</A>
> > > <A HREF ="http://www.nbiracing.com">http://www.nbiracing.com</A>
> > > <A HREF ="http://www.yourlottosite.com">http://www.yourlottosite.com</A>
> > >
> >
> > >
> > >
> > >> So the bottom line is ... MM5 is not quite ready for MySQL?
> > >>
> > >> Leslie
> > >>
> > >>
> > >>> In most scenarios, the MM5 would not need the load balancing
> across
> > >>> multiple servers, so the issue would not come up. But when a
> store
> > >>> decides it wants that load balancing, there will be database
> issues
> > >>> along
> > >>> with the issue of needing mirror scripts copies of the modules.
> > >>> Updating
> > >>> module versions (3rd party and miva core) will be a headache. It
> is
> > >>> one
> > >>> thing for the host to unzip multiple copies of core mvc files, but
> what
> > >>> about the new update wizard. It is going to flow the new module
> > >>> versions
> > >>> to one location. So you will have one server updated with new
> scripts
> > >>> and
> > >>> others not. It definitely is going to require some sort of
> technique
> > >>> to
> > >>> put all scripts on the single server. If that is done, then it
> might
> > >>> not
> > >>> be an issue with the data either. This is going to be a trial and
> > >>> error
> > >>> experimentation. I would hope that hosts share their knowledge
> rather
> > >>> than "trade secret" these issues. Film at 11.
> > >>>
> > >>>
> > >>> --
> > >>> Bill Weiland - Emporium Plus <A HREF ="http://www.emporiumplus.com/store.mvc">http://www.emporiumplus.com/store.mvc</A>
> > >>> Modules for eCommerce. Mail Mgr, Coupon, Rate This, Wait List Mgr,
> > >>> PayPal, Gift/Wish List, Froogle data feed, Shipping & dozens more
> > >>> Online Documentation <A HREF ="http://www.emporiumplus.com/tk3/v3/doc.htm">http://www.emporiumplus.com/tk3/v3/doc.htm</A>
> > >>> Question
> <A HREF ="http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=SPTS">http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=SPTS</A>
> > >>> |
> > >>>
> > >>> ---- David Hubbard <[email protected]> wrote:
> > >>>> From: William Weiland
> > >>>> >
> > >>>> > The modules within merchant were written that way because
> > >>>> > they have had a year or two to write them. You know how
> > >>>> > long we have had since Miva settled on how and where the
> > >>>> > data would be located and files named. So the suggested
> > >>>> > first step was to use the old access method for your
> > >>>
> > >>>> > module's own configuration and concentrate on the mivasql
> methods
> > >>>> for
> > >>>> > accessing store data (products/cats/orders/etc). The next
> step,
> > >>>> which
> > >>>> > will take considerable time if the module has a lot of
> configuration
> > >>>> > databases, will be to convert the module's internal data to
> mivasql
> > >>>> > calls.
> > >>>>
> > >>>> Ah, I didn't realize that was even an option. That
> > >>>> definitely would raise some issues with load balancing;
> > >>>> those considering it would need to ensure that the
> > >>>> modules they are using have been written using the
> > >>>> SQL method so no surprises result.
> > >>>>
> > >>>> David
> > >>>>
> >
> >
> >
> >

MySQL question



From: Jen Ferraz

> Load balancing aside, which most stores
> will not need to do, are there any other
> issues you see with using MySQL and
> third party modules?

Yes, for example it is the inability to use active filter expressions (resp.
queires in SQL) that with the old xBase can be used and can be designed to
change their behaviour dynamically while running through the database. The
other possible/probable problem is the inability to use functions in the
queries that can be then applied on the database records, as it can be done
in standard xBase MvFILTER (I did not investigate it yet though, so cannot
tell for sure if it is indeed unavailable now). There are plenty of other
compatibility problems that need workarounds or completely different
approach, but it is very likely we will bounce into many of them later, when
there are more v5 stores are running 3rd party modules.

Ivo Truxa

| http://miva.truxoft.com
| Advanced Miva Merchant modules

MySQL question



Bill,

This all depends on how you do load balancing, like David said...

In our case, we load balance both the users htdocs directories as well
as the mivadata directories on Netapp NFS filers, so in this case, we
shouldn't have any of these issues, because any module configuration
dbf's will still reside in the mivadata directory as they have in the
past, and all machines responding will have access to those, as well as
the modules scripts.

I think the best thing for the users with mysql is that the search
performance will be a thousand fold performance increase for
sure...(depending on the structure I suppose).

Its kind of a bummer that the setup makes you choose between mysql and
dbf files, and once you choose, you're stuck with your store that way.
Maybe in the future, you will be able to move from one to the other...

Tim.




William Weiland wrote:

>It is but you are going to have some admin issues if you are doing load balancing across multiple servers. If your scripts are in one place and your data is in one place, I don't see any problems with any of the data access methods. And as David pointed out, there are probably some ways these issues can be resolved but the product has only been out for 4 days and very little discussion has been going on about things to consider. Also, hosts may jealously protect their techniques to gain an advantage, so each host might need to climb that slippery slope to find the best path. I hope that is not the case. I hope Miva Corp comes out and says here is "best practice" for doing the configuration and updating when:
>1) you use mysql - one server for data and one for scripts
>2) you use mysql - one server for data and multiple for scripts
>3) you use mivasql with only mivasql calls to data
>4) you use mivasql AND tradional dbf calls to data
>
>
>

MySQL question



This sounds like really good news. So if I mvcreate a standard dbf file from a mivascript application and the vm config is setup to put the data on a certain server, then that data will be accessible even in a load balanced environment? I didn't get that impression from the meeting last weekend. Perhaps the file locking mechanism will be an issue. I guess I need to find someone who has mysql and load balanced and see if they will test a module. Or switch my test store to mysql.

Like you said, switching back and forth is not possible. I suppose one could delete the Merchant5 data directory and start from scratch. I think I'll have to do that anyway based on the fact I haven't received my free upgrade license yet (2004 Miva conference attendees and the other as a partner) and when I do they will likely be different from the testing license. In the old days editing the dbf file to correct the license wasn't a big deal. It will be if we can't easily get to the databases. Seems like there should be an input to change the license key.

--
Bill Weiland - Emporium Plus <A HREF ="http://www.emporiumplus.com/store.mvc ">http://www.emporiumplus.com/store.mvc </A>
Modules for eCommerce. Mail Mgr, Coupon, Rate This, Wait List Mgr,
PayPal, Gift/Wish List, Froogle data feed, Shipping & dozens more
Online Documentation <A HREF ="http://www.emporiumplus.com/tk3/v3/doc.htm ">http://www.emporiumplus.com/tk3/v3/doc.htm </A>
Question <A HREF ="http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=SPTS ">http://www.emporiumplus.com/mivamodu...vc?Screen=SPTS </A>
|

---- Tim Traver <[email protected]> wrote:
> Bill,
>
> This all depends on how you do load balancing, like David said...
>
> In our case, we load balance both the users htdocs directories as well
> as the mivadata directories on Netapp NFS filers, so in this case, we
> shouldn't have any of these issues, because any module configuration
> dbf's will still reside in the mivadata directory as they have in the
> past, and all machines responding will have access to those, as well as
> the modules scripts.
>
> I think the best thing for the users with mysql is that the search
> performance will be a thousand fold performance increase for
> sure...(depending on the structure I suppose).
>
> Its kind of a bummer that the setup makes you choose between mysql and
> dbf files, and once you choose, you're stuck with your store that way.
> Maybe in the future, you will be able to move from one to the other...
>
> Tim.
>
>
>
>
> William Weiland wrote:
>
> >It is but you are going to have some admin issues if you are doing load balancing across multiple servers. If your scripts are in one place and your data is in one place, I don't see any problems with any of the data access methods. And as David pointed out, there are probably some ways these issues can be resolved but the product has only been out for 4 days and very little discussion has been going on about things to consider. Also, hosts may jealously protect their techniques to gain an advantage, so each host might need to climb that slippery slope to find the best path. I hope that is not the case. I hope Miva Corp comes out and says here is "best practice" for doing the configuration and updating when:
> >1) you use mysql - one server for data and one for scripts
> >2) you use mysql - one server for data and multiple for scripts
> >3) you use mivasql with only mivasql calls to data
> >4) you use mivasql AND tradional dbf calls to data
> >
> >
> >
>
>

MySQL question



That's about 15 questions that so depend on other answers.
If you client isn't connecting directly to his merchant databases now,
why would he want to directly connect to them with mm5.
Where is he hosted, they may have a control panel for myssql... if not,
then phpmyadmin would work... but again.. why? He could really break
things by going right into the db.

MM5 comes with all it needs to connect to mysql.. but mysql isn't a part
of mm5.. it's a seperate thing. mysql would have to be installed on the
server so the store can utlize it.

If you have purchased software that requires mysql, then you ahve to
have the lisc ver on mysql not the freebit gnu... often hosts have
already got this squared away so you don't need to worry, but many hosts
only provide the freebie mysql... it's kinda sticky and confusing...

David posted some good stuff on the issues about it and a copy of the
hosts have asked Miva some questions about it. It is possible that Miva
has paid a fee to mysql to cover commercial use by anyone using their
shopping cart software... but then again... maybe not. The onus may be
passed on to the hosts or the store owners... Somehow I feel it's a go
down the chain kind of thing.... pass the buck on... but until Miva
posts an answer on it, we don't know. I would practice cya if I were you.

Kelly

Leslie Nord - Webs Your Way wrote:

>Could I get a good explaination for my client's questions?
>
>So if I wanted to upgrade to MM5 so I could use MySQL as an underlying
>database, how would I connect to MySQL once upgraded? Is Miva shipping
>the MySQL client libraries with MM5? If MM5 is currently available, how
>is it being done now?
>
>Leslie
>www.websyourway.com
>Miva Merchant Maintenance and more ... since 1998
>
>

MySQL question



On 5/5/05, William Weiland <[email protected]> wrote:
> This sounds like really good news. So if I mvcreate a standard dbf file =
from a mivascript application and the vm config is setup to put the data on=
a certain server, then that data will be accessible even in a load balance=
d environment? I didn't get that impression from the meeting last weekend.=
Perhaps the file locking mechanism will be an issue. I guess I need to f=
ind someone who has mysql and load balanced and see if they will test a mod=
ule. Or switch my test store to mysql.

Based on what Dave's saying, file locking should be fine also as the
files will all be in one place.

Must admit, this has been a great thread. Never fully understood load
balancing, always thought you'd have to run a copy of Merchant on each
server, and just have one DB backend. Now I _think_ I get it...

1 server hosts the scripts as a shared server for the scripts. It
doesn't have to run them (but it could if it's also acting as one of
the distributed servers - is this common?). It's basic job is to
simply be a file server (no worse than dishing out static html pages)

All of the distributed servers just read the file from the script
server, then they each run the script, so the distributed servers are
taking the CPU/RAM hit.
=20
So you have a single source for the scripts (no multiple
installations/upgrades), but multiple CPUs and RAM banks.

Thanks much Dave for the clear answers, and Bill for asking some good quest=
ions.

> Like you said, switching back and forth is not possible. I suppose one c=
ould delete the Merchant5 data directory and start from scratch. I think I=
'll have to do that anyway based on the fact I haven't received my free upg=
rade license yet (2004 Miva conference attendees and the other as a partner=
) and when I do they will likely be different from the testing license. In=
the old days editing the dbf file to correct the license wasn't a big deal=
. It will be if we can't easily get to the databases. Seems like there sh=
ould be an input to change the license key.
>=20
> --
> Bill Weiland - Emporium Plus <A HREF ="http://www.emporiumplus.com/store.mvc">http://www.emporiumplus.com/store.mvc</A>
> Modules for eCommerce. Mail Mgr, Coupon, Rate This, Wait List Mgr,
> PayPal, Gift/Wish List, Froogle data feed, Shipping & dozens more
> Online Documentation <A HREF ="http://www.emporiumplus.com/tk3/v3/doc.htm">http://www.emporiumplus.com/tk3/v3/doc.htm</A>
> Question <A HREF ="http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=3DSPTS">http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=3DSPTS</A>
> |
>=20
> ---- Tim Traver <[email protected]> wrote:
> > Bill,
> >
> > This all depends on how you do load balancing, like David said...
> >
> > In our case, we load balance both the users htdocs directories as well
> > as the mivadata directories on Netapp NFS filers, so in this case, we
> > shouldn't have any of these issues, because any module configuration
> > dbf's will still reside in the mivadata directory as they have in the
> > past, and all machines responding will have access to those, as well as
> > the modules scripts.
> >
> > I think the best thing for the users with mysql is that the search
> > performance will be a thousand fold performance increase for
> > sure...(depending on the structure I suppose).
> >
> > Its kind of a bummer that the setup makes you choose between mysql and
> > dbf files, and once you choose, you're stuck with your store that way.
> > Maybe in the future, you will be able to move from one to the other...
> >
> > Tim.
> >
> >
> >
> >
> > William Weiland wrote:
> >
> > >It is but you are going to have some admin issues if you are doing loa=
d balancing across multiple servers. If your scripts are in one place and =
your data is in one place, I don't see any problems with any of the data ac=
cess methods. And as David pointed out, there are probably some ways these=
issues can be resolved but the product has only been out for 4 days and ve=
ry little discussion has been going on about things to consider. Also, hos=
ts may jealously protect their techniques to gain an advantage, so each hos=
t might need to climb that slippery slope to find the best path. I hope th=
at is not the case. I hope Miva Corp comes out and says here is "best prac=
tice" for doing the configuration and updating when:
> > >1) you use mysql - one server for data and one for scripts
> > >2) you use mysql - one server for data and multiple for scripts
> > >3) you use mivasql with only mivasql calls to data
> > >4) you use mivasql AND tradional dbf calls to data
> > >
> > >
> > >
> >
> >

MySQL question



From: William Weiland
>=20
> This sounds like really good news. So if I mvcreate a=20
> standard dbf file from a mivascript application and the vm=20
> config is setup to put the data on a certain server, then=20
> that data will be accessible even in a load balanced=20
> environment?

The only time this will occur is when the hosts'
setup includes multiple servers using shared storage
for the script AND data files. That's not guaranteed
to be the case as you can also load balance with
separate copies of Merchant on each web server all
configured to either use a shared mivadata directory
or, in MM5's case, a single back-end mysql server.

> I didn't get that impression from the meeting last
> weekend. Perhaps the file locking mechanism will be an=20
> issue. I guess I need to find someone who has mysql and load=20
> balanced and see if they will test a module. Or switch my=20
> test store to mysql. =20

Locking will only be an issue when using dbf files on
shared storage, but Empresa includes a shared-storage-safe
locking mechanism so there should not be problems in that
setup. MySQL-based load balancing greatly removes a lot
of the overhead compared to mivadata on shared storage
load balancing because you no longer have multiple servers
competing for access to the same files, you just have=20
multiple servers issuing queries to one mysql server
and it worries about the locking and unlocking of tables
in mysql.

David

MySQL question



From: Bill Guindon
>=20
>=20
> Must admit, this has been a great thread. Never fully understood load
> balancing, always thought you'd have to run a copy of Merchant on each
> server, and just have one DB backend. Now I _think_ I get it...

Technically you are running Empresa and Merchant on each
server, they just might be sharing at least the same data,
or at most the same files as well.

> 1 server hosts the scripts as a shared server for the scripts. It
> doesn't have to run them (but it could if it's also acting as one of
> the distributed servers - is this common?). It's basic job is to
> simply be a file server (no worse than dishing out static html pages)

Correct, you can dedicate a server to this task, use one of
the web servers or database server for it or even a specialized
piece of hardware that just shares files like what Tim uses.
The most reliable, and easiest, way to do load balancing is
hardware on the front end, multiple servers sharing the same
files, and then single database server on the backend if the
application in question uses mysql, such as Merchant 5.

> All of the distributed servers just read the file from the script
> server, then they each run the script, so the distributed servers are
> taking the CPU/RAM hit.

Correct, you get a nearly linear increase in traffic handling
as long as the application is written in a way that doesn't
degrade as multiple servers try hitting the same database.
For example, if Merchant is doing something that is long
running and also involves locking an entire table in mysql,
your mysql server could ultimately become the weakest link
as it has to be able to scale its query-handling abilities
to the level that the multiple web servers are sending.

David

> So you have a single source for the scripts (no multiple
> installations/upgrades), but multiple CPUs and RAM banks.
>=20
> Thanks much Dave for the clear answers, and Bill for asking=20
> some good questions.
>=20
> > Like you said, switching back and forth is not possible. I=20
> suppose one could delete the Merchant5 data directory and=20
> start from scratch. I think I'll have to do that anyway=20
> based on the fact I haven't received my free upgrade license=20
> yet (2004 Miva conference attendees and the other as a=20
> partner) and when I do they will likely be different from the=20
> testing license. In the old days editing the dbf file to=20
> correct the license wasn't a big deal. It will be if we=20
> can't easily get to the databases. Seems like there should=20
> be an input to change the license key.
> >=20
> > --
> > Bill Weiland - Emporium Plus <A HREF ="http://www.emporiumplus.com/store.mvc">http://www.emporiumplus.com/store.mvc</A>
> > Modules for eCommerce. Mail Mgr, Coupon, Rate This, Wait List Mgr,
> > PayPal, Gift/Wish List, Froogle data feed, Shipping & dozens more
> > Online Documentation <A HREF ="http://www.emporiumplus.com/tk3/v3/doc.htm">http://www.emporiumplus.com/tk3/v3/doc.htm</A>
> > Question =
<A HREF ="http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=3DSPTS">http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=3DSPTS</A>
> > |
> >=20
> > ---- Tim Traver <[email protected]> wrote:
> > > Bill,
> > >
> > > This all depends on how you do load balancing, like David said...
> > >
> > > In our case, we load balance both the users htdocs=20
> directories as well
> > > as the mivadata directories on Netapp NFS filers, so in=20
> this case, we
> > > shouldn't have any of these issues, because any module=20
> configuration
> > > dbf's will still reside in the mivadata directory as they=20
> have in the
> > > past, and all machines responding will have access to=20
> those, as well as
> > > the modules scripts.
> > >
> > > I think the best thing for the users with mysql is that the search
> > > performance will be a thousand fold performance increase for
> > > sure...(depending on the structure I suppose).
> > >
> > > Its kind of a bummer that the setup makes you choose=20
> between mysql and
> > > dbf files, and once you choose, you're stuck with your=20
> store that way.
> > > Maybe in the future, you will be able to move from one to=20
> the other...
> > >
> > > Tim.
> > >
> > >
> > >
> > >
> > > William Weiland wrote:
> > >
> > > >It is but you are going to have some admin issues if you=20
> are doing load balancing across multiple servers. If your=20
> scripts are in one place and your data is in one place, I=20
> don't see any problems with any of the data access methods. =20
> And as David pointed out, there are probably some ways these=20
> issues can be resolved but the product has only been out for=20
> 4 days and very little discussion has been going on about=20
> things to consider. Also, hosts may jealously protect their=20
> techniques to gain an advantage, so each host might need to=20
> climb that slippery slope to find the best path. I hope that=20
> is not the case. I hope Miva Corp comes out and says here is=20
> "best practice" for doing the configuration and updating when:
> > > >1) you use mysql - one server for data and one for scripts
> > > >2) you use mysql - one server for data and multiple for scripts
> > > >3) you use mivasql with only mivasql calls to data
> > > >4) you use mivasql AND tradional dbf calls to data
> > > >
> > > >
> > > >
> > >
> > >

MySQL question



That 'easy access' part is all a matter of opinion and what you are
trying to do.
I find it incredibly easy to go edit a record using phpmyadmin.. say I
want to change a word or something.
But in someways it is more difficult. You can't just copy your mivadata
to your local pc, do stuff in mia and then reupload the mivadata directory.
It is easy to delete a bunch of records at once in mysql... but when
they are gone they are gone... you can't 'undelete' them.
It is easy to add new fields and expoit them, or if you want to create a
seperate application and use hte store data.. mysql makes that easy...
It's pretty much like comparing apples and oranges.

The hacking issue doesn't have to do with mysql itself. You can hack
miva 4.x if you know the query commands (I've been told) to put in.
The biggest hacking issues on mysql based stuff is that the applications
themselves weren't written with security in mind to prevent people from
stuff a query inside a form field.

If you don't 'clean' your inputs and outputs (check them to make sure
they contain what you expect them to).
You can see some of this security in Merchant where you can allow or
disallow extended characters to be used in user id's.
You can see how Miva has tried to implement that also with the older pay
flow pro payment modules that wouldnt' accept extended asii chracters in
the data input like O umlaut.
Glad they did fix or expand the payment module, we sell a lot to europe
and it's kinda confusing if not downright insulting not to be able to
spell your name or address properly.
Whatever database is behind the software... the cleaning of the input
should occur. I'm sure Miva has done that to the extent they feel is
necessary...
But whether it is mysql or mivasql or dbf files... the databases are
vulnerable if the inputs are

I"m not sure of the other ramifications of mm5 and mysql,

Kelly




William Weiland wrote:

>Leslie Nord - Webs Your Way wrote:
>
>
>>Could I get a good explaination for my client's questions?
>>
>>So if I wanted to upgrade to MM5 so I could use MySQL as an underlying
>>database, how would I connect to MySQL once upgraded? Is Miva shipping
>>the MySQL client libraries with MM5? If MM5 is currently available, how
>>is it being done now?
>>
>>Leslie
>>www.websyourway.com
>>Miva Merchant Maintenance and more ... since 1998
>>
>>
>
>Unless there is some underlying reason why you need mysql, you might
>want to use the mivasql. Mivasql you will still have easy access to
>your data (same access as you had in 1-4.x merchant). Mysql you will
>not. Mivasql is likely to be compatible with all 3rd party modules.
>Mysql may not (in fact mine won't be mysql ready for several months
>whereas 50 of them are mivasql compatible today). The Miva Corp folks
>probably have a better handle on data security with their proprietary
>mivasql approach vs the mysql which has been hacked by many. I could go
>on with the list. There are pluses and minuses for both approaches.
>
>
>

MySQL question



On 5/5/05, David Hubbard <[email protected]> wrote:
> From: Bill Guindon
> >
> >
> > Must admit, this has been a great thread. Never fully understood load
> > balancing, always thought you'd have to run a copy of Merchant on each
> > server, and just have one DB backend. Now I _think_ I get it...
>=20
> Technically you are running Empresa and Merchant on each
> server, they just might be sharing at least the same data,
> or at most the same files as well.

'run' was a poor choice of words on my part. I should have used
'install' in it's place.

I see from your other post that installing multiple copies of Merchant
is one approach, but the maintenance issues that Bill mentioned
(upgrades, images, etc.) would seem to make that a poor choice.


--=20
Bill Guindon (aka aGorilla)