[stud_muffler]

When trying to upload an image in the Stuff/Media I'm getting:

Quote

SQLSTATE[HY000]: General error: 1364 Field 'description' doesn't have a default value

8)

[Alex]

Do you have phpmyadmin or similar? Or mysql on the command line?

If so, edit the fruml_media table and set the description column to allow NULL values. That should fix it.

[stud_muffler]

I set it to have a default value of 'Enter description'.

BTW when I was editing/fixing missing icons for the sites I notice that there is no way of using previously uploaded  media content vs. new upload. Sounds like a feature request...  ;)

8)

[Alex]

That's not a bad idea - I guess some sort of light-weight media browser for choosing icons (wherever there are icons) might be handy.

I suppose that such a browser could even replace new icon uploads altogether, so that if you wanted an icon somewhere, you'd have to upload it through the media functions. That might be going to far though :)

But I like this idea. The current uploads for icons can be quite troublesome (what with resizing etc).

[stud_muffler]

Another thing about database.
Not sure if it was by design.
There are four tables (custom_tag, locale, media, media_category)  that are using MyISAM engine and rest of the tables are using InnoDB.

8)

[Alex]

Oops, I still need to change them over to InnoDB.
I'm pretty sure there are no queries using transactions on those tables yet, but there might be at some point, and then they'll need to be InnoDB. Well spotted!

[Nazariy]

Alex, on 21 January 2010 - 09:48 PM, said:

Oops, I still need to change them over to InnoDB.
I'm pretty sure there are no queries using transactions on those tables yet, but there might be at some point, and then they'll need to be InnoDB. Well spotted!

Is it really necessary to have all tables in InnoDB format?

Some people think that MyISAM is kind of old fashion out of date mechanism and should be avoided, but its not true.
As from my experience:

• InnoDB is much slower than MyISAM for simple select queries.
  
• InnoDB support transactions and foreign keys, but when do we need them and how much would we trust MySQL for cascading delete or update routine? In many case we still need to control this procedure from application level.
  
• They handle indexing differently and for example InnoDB does not know how many records table contain and gives you approximate result when number is greater than 1000 MyISAM instead always know correct amount of records.
  
• Another difference between them that MyISAM does table level locking while InnoDB can do row level locking. Benefits from InnoDB could be for messaging systems or writing some sort of visitor statistic when you have to do read-write queries to different tables simultaneously.
  
• MyISAM supports (non-standard-SQL) fulltext indexing which InnoDB still does not.
  
• Backup process is handled better in MyISAM than InnoDB due to table locking.
  
• InnoDB takes more space on hard drive and consume more memory comparing to MyISAM (some hosting companies have restrictions on database size and allocated memory)

Of course InnoDB is new and has its own benefits, but I think only enterprise level applications could benefit from them.

I hope this information would help to make your application better and faster.

Here is some more information about difference and benefits of MyISAM vs InnoDB

[Alex]

Currently all tables except for one are InnoDB. This is because I want to use foreign key constraints/ cascades as much as possible as well as transactions.
Over time though, some tables which use none of these can/ will be altered to use MyISAM. I'm just not at that stage yet. So eventually a number of tables will use InnoDB in order to leverage transactions and constraints, and some tables will be MyISAM.

I think the performance difference between InnoDB and MyISAM is negligible for selects (I see no difference on my machine). For inserts, deletes and updates MyISAM is definitely a lot faster, but as these actions are *generally* carried out within the CMS and not on the front-end pages, that shouldn't be too much of a problem.