Thread

Ronnie, notice of build updates are posted to the Build forum (and have for over two years I might point out) for which you can subscribe to the feed, and the changes are also mirrored in the user guide change log.

Thanks Derek. Got it.

😊

I’m still trying to figure out whether to update a site with a new build four days or five days or a week after the most recent build, since yet another build always seems to come out one day after I update all the sites. It’s like you guys watch the sites to see… when I update, then you release a new build.

Arrrgh!!

😊

Keep up the good work!

LOL I promise that’s not what I did.  This time.

Switched from || to OR in queries, for the benefit of people using MySQL servers running in the SQL Mode “PIPES_AS_CONCAT”

Does this mean we can’t use the ‘||’ in exp:query any more?

Switched from || to OR in queries, for the benefit of people using MySQL servers running in the SQL Mode “PIPES_AS_CONCAT”

Does this mean we can’t use the ‘||’ in exp:query any more?

No, we switched our own queries, you can still use what you like.  If you’re building an add-on though, it would be friendly to people on these environments to use OR instead of pipes.  Personally, I find it much more legible as well, particularly when viewed with different type faces.

Hey Derek,

I was just curious of the new way field formatting is stored in EE 1.6.5
It went from VARCHAR(40) to TINYTEXT.

Does that really make a difference?
I looked up some articles on VARCHAR VS TINYTEXT and they all prefer VARCHAR.

The length of varchar fields contributes to the row length, which some people in extreme edge cases were hitting, preventing them from creating the custom fields that they need.  The argument for varchar over tinytext is that blob/text family columns are stored as disk based tables separately from the table that contains them, so all queries for such fields will use filesort instead of heap (memory) tables.  That’s already the case with the exp_weblog_data table though, since custom fields have to be text type to be large enough to hold the content.  So in this case, changing the field formatting columns to a text family column has two positive effects: first, they no longer contribute to the row length, increasing the number of potential custom fields from a few hundred to a few thousand.  Second, more of the queried data is stored together, even though it’s off table, which surprisingly enough makes queries and operations on this table faster than when the field format column was stored in-table as a varchar field.  In some cases, the gain is as much as 20% faster performance for queries to that table.  Sorting and filtering is never done based on these columns, so there’s no additional negative impact there either.

I would have learned something too if I understood half of what was written 😉

All sounds good though so that’s good! 😊

Best wishes,

Mark