Hi Neel,

I am sorry for the delay of this reply.

Yes, currently the db table creation script definition has defined the engine to be 'MYISAM'. Please see http://screen.stackideas.com/2014-11-08_1555.png

Hope this help and have a nice day!

Thank you for confirming that Sam. Is there any reason ES specifies MyIsam? Is there any MyIsam specific features it requires? If not, it's probably better not to mention the storage engine during installation so it automatically chooses the default engine based on the environment. My server is specially tuned for Innodb so that works best. I am pretty sure most Vps / dedicated servers (except shared hosts) have higher configurations allocated for Innodb. There are many features Innodb provides that MyIsam can't. So unless there is a particular need for using MyIsam, I don't see the point for ES to specifically choose MyIsam as the SE. Could this be updated plz after checking to see if it's okay to use ES on any of the storage engines with no issues?

Hi Neel,

When we develop EasySocial, we actually designed the db in MyISAM engine thus currently EasySocial was tested only in MyISAM engine. I do remember few of our customer actually recreate the db tables in InnoDB engine and I haven't heard of any complaint from them. Thus, I believe it should work well with InnoDB but again, we haven't tested with InnoDB yet. You might want to give it a try again.

Hope this help.

Okay... Can you confirm this please:

Is there any MyIsam specific features EasySocial requires?

If it doesnt, then its safe to say that InnoDB can be used as a drop-in replacement without any issue. However, its not easy to transfer an existing installation from MyISAM to InnoDB. However, for new installations I dont see an issue. I do strongly feel you should not mention storage engine (myisam) during installation. This is limiting in a lot of ways. You should perhaps leave it without mentioning the SE so it defaults based on the server environment of the user. Even if I do manually change MyIsam to InnoDB during the new installation, this could still cause problems in the future during upgrades when new tables are created and table definition explicitly specifies MyIsam. This causes a lot of headaches which can be easily avoided.

Can you consider removing the mention of Storage engine in the installation script so it automatically defaults to users server set-up?

Thanks Sam. Can you consider adding this to your next minor release of ES? It's been a long time since default db engines has been changed from MyIsam to Innodb for Mysql and Mariadb. Although you haven't tested with Innodb, there should be no problems as far as ES tables are concerned. Not mentioning the SE will be the best way to go with it..

Hi Neel,

Thanks for the heads up on this one. We will see if we can include this into next release or future releases of EasySocial.

Hope this help and have a nice day!

Hi Sam, Can you give me an estimation on when you might be including this with Easysocial? Next I will start setting up my new server for the production site and most of the mysql tuning is hugely dependent on this. I dont want to be poking around the sql tables each time to change storage engine to default engine everytime I update or install EasySocial. So can you give me a more concrete answer if you can plz..

ps: plz dont lock this topic yet

Hi Neel,

I am sorry for the delay of this reply.

I am very sorry but currently I cannot give you an estimation on when we can include this feature into EasySocial as we are currently focusing on EasyBlog 5 and most likely there will not be any major release for EasySocial 1.3.x

Most likely we will add this into EasySocial 1.4.

Hope this help and have a nice day

Sorry Sam...just a last question. But isint it just a matter of not mentioning the storage engine in the table creation script? As it is a very minor edit, can you consider adding this to 1.3.13 release plz? I am sorry for hassling you on this. But it's just that 1.4 is a far way away and this edit is a minor thing which let's user use their default engine, that's all..

Hi Neel,

I can take out the db engine definition in few minutes time but the matter is we need to go through a proper test before we can release it as a stable version. I hope you can understand this. We are not able to take such risk

Hope this help

Fair enough. Thank you Sam.

Hi Neel,

Thank you for your understanding

Hi Sam, I am now gonna manually change the database engine to Innodb for easysocial tables and see if that causes any issues. Can you quickly clarify these plz:

1) Does any easysocial require full text search or spatial index feature for any tables?
2) Does anything use BLOB at all?

Both Now or in the future?

Hello Neel,

I am sorry for the delay of this reply.

1) Does any easysocial require full text search or spatial index feature for any tables?

Yes, EasySocial's tables does require fulltext indexes on table jos_social_fields_data and this fulltext index is used in friend suggestion search. As for spatial index feature, currently we don't use any of the spatial indexes.

2) Does anything use BLOB at all?

Yes, currently we store EasySocial backend settings in our config table on a blob type column. Take a look at this table jos_social_config.

Hope this help and have a nice day

Thanks Sam. I'll then need to re-evaluate if I do wanna change to Innodb then. I heard that Innodb doesn't do so well when it comes to fulltext search or anything with long texts like blob. Hm... Maybe I'll just leave it as MyIsam and re-tune my server since I don't need to allocate big resources for Innodb anymore. I am assuming there might already be a lot of big high traffic sites out there using Easysocial on MyIsam with no problems isint it... Probably better if I don't poke around too much especially when you don't support Innodb just yet.

Thanks again Sam for being patient with me.

subscribe

right now easysocial did go 1.4 ,is using innodb or still myisam ?

This is what one of my servers admint told me about myisam when i have using k2 and the database was about 2gb and about 200k items :
"
As for the MYSQL Table Crashes, your table is a MyISAM Table, which is prone to crashing if the table is Large or if the Table receives a lot of Traffic"

Myisam will crash if the table is large ,if it does get alot of traffic,or both.

Hey Electro,

We are actually using MyIsam but it does not mean that it would crash more often. There are pros and cons of using myisam and innodb and innodb offers rollback and transactions which we don't actually use. You can actually read more about it from the following links:

http://www.rackspace.com/knowledge_center/article/mysql-engines-myisam-vs-innodb
http://stackoverflow.com/questions/12614541/whats-the-difference-between-myisam-and-innodb

Hi Mark,

If the queries will be optmized maybe it won`t crash,however as you grow i don`t think myisam is suitable.

Try to do if possible an test with an network of 1milion of members,or even 100k members,and also simulate some traffic over traffic,and let me know,if it does crash or not.Or maybe they are some people that did succed to achieve this number with your products.

From my bad experience with the k2 component,after 100k items,the table start having problems,that does not mean same thing it will happen with your products,it does mean,you have to find out an way to test it,and make some research.
On 200k items it wasn`t operable at all.

I also,don`t tell you,to change right the way from myisam to innodb,but i think you should definetely think on this in future version and on an remote storage integration with amazon cloud drive and amazon s3,will be nice for start,in order to remote store the files,else if you have an nerd member that starts to upload all his videos or his photos into your OWN server and you don`t have enough space,it might actually crash it right the way.

And what is writed on rackspace : Note: A MyISAM table that is using FULL TEXT Indexing can not be converted to an Innodb Table Engine type. ,this is not true.

It can be converted with full text,but not on mysql 5.5,you have to update to mysql 5.6 witch in my case,blow up the entire setup,seems they are problem with it : http://dba.stackexchange.com/questions/64607/mysql-server-taking-up-100-cpu

And i upgraded it to mariadb,witch actually did solve the problem and runs alot more better then mysql.

Actually mariadb,is practically the same guy that invented mysql ,but right now mysql is in hands of Oracle,so mariadb is more open source then mysql,and even google and wikipedia are earlier adopters,and i think the trend will continue,booking.com also go with mariadb.

Hey Electro,

This is under the assumption that everyone uses MySQL 5.6 but we have a huge list of clients that is still on MySQL 5.0 even. As much as we want to move over, we still need to consider these compatibility issues.

In fact, in one of the releases on EasySocial 1.2.x, we were using stored procedures and you couldn't imagine the nightmare we faced because of this. There are just so many hosting companies who doesn't allow stored procs

This isn't just applied to MySQL, php even. There are still many hosts that runs on PHP 5.2

Hi Mark,

Of course,mysql 5.6 or mariadb is need it,more exactly mariadb much more better then mysql.

I think that huge list of clients,they should upgrade their servers,as even joomla 3.4.4 is hackable,if you use mysql 5.0 or php 5.2 i think your having an high risk of being hacked,as those versions are not supported anymore,it`s enough one smart guy to find an 0 day exploited,and your done.

I know is hard to keep up with latest technology,but people that stays and live in the past,they are facing security risk,that can cost them,more then an simple update from mysql 5.0 to mysql 5.6 for example.Or from php 5.2 to php 5.5 or php 5.6.

I think that people does not realize what risk they are taking,running software uncovered by security updates.
Is no wonder so many websites are hacked nowdays or taken down,the fault is on the side.

Your clients should be aware of that risk,and move forward with the world !

The updates from mysql 5.5 to mariadb is smooth,updating from php 5.4 to php 5.5 again is not such an big deal .

Not to say,that they don`t have their own server,and they can ask their server admin to do that,and if they can`t ,what the heck to stay on an unsecured host ?! Move forward to another host.

From my point of view things are simple.

And i don`t think stackideas should be stuck in the past,because some people does not care about their own security,and don`t have 1 hour,to update their software.

From my point of view,they should upgrade,and they should follow stackideas product development,and not stackideas to follow them.

What are the reason of somebody wanting to stay on mysql 5.0 or php 5.2 ??To load more lazy?To be hacked more often ?Or because they are too lazy or their sis admins are too lazy to apply some software updates?!

Hi Electro,

Thanks for the heads up on this one. I do agree with you people should always keep their software up-to-date. Thanks for the info, didn't know that mariadb actually invented from someone from MySQL Will definitely give mariadb a try

Thanks and have a nice day!

Hi,

It will worth it.

I wanted to ask ,in order an user to not have to upload his avatar in easyblog,easysocial or jomsocial ,i did not find no option for example into the integration of jomsocial and neither at least on your own product easysocial,to be able the user,to use same avatar ?

That basically means,he does not have to upload his avatar in easyblogg,jomsocial and easydiscuss,and one avatar uploaded in any of this to be can be used across the whole website.

Is that possible !? Maybe i missed this setting...

Hi Electro,

I am really sorry for the delay of this reply.

You can actually override easyblog default avatar by referring to our documentation here, http://stackideas.com/docs/easyblog/administrators/how-tos/how-to-override-default-blogger-avatar . You can then set the default avatar to use the same avatar as other components. Hope these could help.

By the way if you have any other inquiry kindly start a new thread so it will be easier for us to assist you with the issue in the future.