MySQL question

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



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.

--
Bill Weiland A2Z Emporium Plus <A HREF ="http://www.emporiumplus.com/store.mvc ">http://www.emporiumplus.com/store.mvc </A>
Modules for eCommerce. Mail Mgr, Coupon, PayPal, Froogle/Yahoo feeds
Rate This, Gift/Wish List, Wait List Mgr, EZ Batch, Shipping & more
Online Documentation <A HREF ="http://www.emporiumplus.com/docs">http://www.emporiumplus.com/docs</A>
Question <A HREF ="http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=SPTS ">http://www.emporiumplus.com/mivamodu...vc?Screen=SPTS </A>
|

MySQL question



>> 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



Yes - my client specifically asked about it. He wants specifics about MySQL.




> 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



From: [email protected]=20
>=20
> Could I get a good explaination for my client's questions?
>=20
> 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?

Empresa 5 has the ability to talk to a MySQL server natively,
the server just has to exist. During setup you tell it to
connect to database@host using the specified username and
password and that's it.

David

MySQL question



From: William Weiland
>=20
>=20
> 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.=20
> 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. =20
> I could go
> on with the list. There are pluses and minuses for both approaches.=20

Bill, what makes a module mivasql-specific? I was under the
impression that the mivasql was just a translation layer
behind the scenes so that a customer or host could use dbf
or mysql as desired?

David

MySQL question



David Hubbard wrote:
>
> From: William Weiland
> >
> >
> > 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.
>
> Bill, what makes a module mivasql-specific? I was under the
> impression that the mivasql was just a translation layer
> behind the scenes so that a customer or host could use dbf
> or mysql as desired?
>
> David

Based on Jen's talk, my impression was if you are load balancing by
having the data on one server, but then having the scripts on multiple
servers, only the mysql would be able to read the dynamic data from all
of the servers with the scripts. If you put the database on each of the
servers with scripts, then the script could read it. But there would
not be a mirror copy of the data if that data dynamically changed, eg
orders, etc.
Is that impression correct? Or did I miss something?

--
Bill Weiland A2Z Emporium Plus <A HREF ="http://www.emporiumplus.com/store.mvc ">http://www.emporiumplus.com/store.mvc </A>
Modules for eCommerce. Mail Mgr, Coupon, PayPal, Froogle/Yahoo feeds
Rate This, Gift/Wish List, Wait List Mgr, EZ Batch, Shipping & more
Online Documentation <A HREF ="http://www.emporiumplus.com/docs">http://www.emporiumplus.com/docs</A>
Question <A HREF ="http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=SPTS ">http://www.emporiumplus.com/mivamodu...vc?Screen=SPTS </A>
|

MySQL question



From: William Weiland
>=20
> Based on Jen's talk, my impression was if you are load
> balancing by having the data on one server, but then
> having the scripts on multiple servers, only the mysql
> would be able to read the dynamic data from all of the
> servers with the scripts. If you put the database on=20
> each of the servers with scripts, then the script
> could read it. But there would not be a mirror copy
> of the data if that data dynamically changed, eg
> orders, etc. Is that impression correct? Or did I
> miss something?

That's correct. You can load balance a Merchant store that
uses dbf files by sharing the mivadata directory amongst
multiple servers in some manner, but my testing of the=20
common ways of doing that showed that the performance
penalty that results was too great to make it practical.
The mysql-based Merchant on the other hand solves this
problem as sending the queries to a local instance is just
a few milliseconds faster than sending them over the network
to a central mysql server.

But my impression of Merchant 5 was that all modules are
written using SQL statements and then if one chooses to
use the mivasql back-end, Miva's translation layer kicks
in and redirects those operations into dbf files. So you
can effectively choose mivasql or mysql on the backend
with no change at the application layer? =20

David

MySQL question



David Hubbard wrote:
> That's correct. You can load balance a Merchant store that
> uses dbf files by sharing the mivadata directory amongst
> multiple servers in some manner, but my testing of the
> common ways of doing that showed that the performance
> penalty that results was too great to make it practical.
> The mysql-based Merchant on the other hand solves this
> problem as sending the queries to a local instance is just
> a few milliseconds faster than sending them over the network
> to a central mysql server.
>
> But my impression of Merchant 5 was that all modules are
> written using SQL statements and then if one chooses to
> use the mivasql back-end, Miva's translation layer kicks
> in and redirects those operations into dbf files. So you
> can effectively choose mivasql or mysql on the backend
> with no change at the application layer?
>
> David

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.

--
Bill Weiland A2Z Emporium Plus <A HREF ="http://www.emporiumplus.com/store.mvc ">http://www.emporiumplus.com/store.mvc </A>
Modules for eCommerce. Mail Mgr, Coupon, PayPal, Froogle/Yahoo feeds
Rate This, Gift/Wish List, Wait List Mgr, EZ Batch, Shipping & more
Online Documentation <A HREF ="http://www.emporiumplus.com/docs">http://www.emporiumplus.com/docs</A>
Question <A HREF ="http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=SPTS ">http://www.emporiumplus.com/mivamodu...vc?Screen=SPTS </A>
|

MySQL question



David Hubbard wrote:
> But my impression of Merchant 5 was that all modules

Another issue. When installing a 3rd party module, the admin upload is
putting it on one server. Who is putting the mirror on all the other
servers when load balancing?

--
Bill Weiland A2Z Emporium Plus <A HREF ="http://www.emporiumplus.com/store.mvc ">http://www.emporiumplus.com/store.mvc </A>
Modules for eCommerce. Mail Mgr, Coupon, PayPal, Froogle/Yahoo feeds
Rate This, Gift/Wish List, Wait List Mgr, EZ Batch, Shipping & more
Online Documentation <A HREF ="http://www.emporiumplus.com/docs">http://www.emporiumplus.com/docs</A>
Question <A HREF ="http://www.emporiumplus.com/mivamodule_wcw.mvc?Screen=SPTS ">http://www.emporiumplus.com/mivamodu...vc?Screen=SPTS </A>
|

MySQL question



From: [email protected]=20
>=20
> David Hubbard wrote:
> > But my impression of Merchant 5 was that all modules=20
>=20
> Another issue. When installing a 3rd party module, the admin=20
> upload is putting it on one server. Who is putting the mirror
> on all the other servers when load balancing?

The server admin managing a load balanced cluster has
to manage that in some way. It would be feasible to
put the script files on shared storage so all the web
servers share the same copy of the scripts since the
I/O demands on that side are minimal; that would avoid
the need to manually replicate the files since the
replication would have to include graphics as well as
even Merchant itself due to the streaming updates.

David

MySQL question



From: William Weiland
>=20
> The modules within merchant were written that way because=20
> 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. =20

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



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/mivamodu...vc?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



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



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>

----- Original Message -----
From: "Leslie Nord - Webs Your Way" <[email protected]>
To: <[email protected]>
Sent: Thursday, May 05, 2005 8:10 AM
Subject: RE: [m5u] MySQL question


> 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



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

--
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:
> 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
> >>
>
>
>
>