Isnt this table required for the process of upgrading a site from non-utf8
database

On 19 October 2016 at 16:39, Phil Taylor notifications@github.com wrote:

Joomla has a table called #__utf8_conversion - this has one row and only
one purpose and once conversion is done this table is useless clutter and
should never have been implemented as a table.

If Joomla wants to be storing 0/1 values it should be in a generic options
table (ala wp_options) and not in a specifically named db table fit for one
purpose only.

Possible future changes:

-

Rename the table to be a generic options table - although no real need
for yet more options...
-

Deprecate and remove the table, moving the converted flag to the json
params elsewhere in the db

Discuss.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#12479, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8cYmGp-di5xY0R8FOa1Nbz-kzqudks5q1kfcgaJpZM4KbMjw
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

Sorry maybe I replied too quickly.

Are you saying that this table should be removed after the conversion has
taken place?

On 19 October 2016 at 16:50, Brian Teeman brian@teeman.net wrote:

Isnt this table required for the process of upgrading a site from non-utf8
database

On 19 October 2016 at 16:39, Phil Taylor notifications@github.com wrote:

Joomla has a table called #__utf8_conversion - this has one row and only
one purpose and once conversion is done this table is useless clutter and
should never have been implemented as a table.

If Joomla wants to be storing 0/1 values it should be in a generic
options table (ala wp_options) and not in a specifically named db table fit
for one purpose only.

Possible future changes:

-

Rename the table to be a generic options table - although no real
need for yet more options...
-

Deprecate and remove the table, moving the converted flag to the json
params elsewhere in the db

Discuss.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#12479, or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8cYmGp-di5xY0R8FOa1Nbz-kzqudks5q1kfcgaJpZM4KbMjw
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

yes... but then it just sits there, does nothing, and doesnt need to be lying around for the next 10 years of Joomla history just to store a single integer!

i think it should be droped in 4.0

We will always need it for people upgrading. The question is if we can
remove it after they have done the upgrade and converted their data

On 19 October 2016 at 16:52, andrepereiradasilva notifications@github.com
wrote:

i think it should be droped in 4.0

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#12479 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8Yxtaa0wf1joSEsXe4fxOkPHP227ks5q1krLgaJpZM4KbMjw
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

The schema parser will groan the table doesn't exist unless its creation is put into a file that the schema parser doesn't check to ensure the database is up to date.

can't we make the upgrade path: mandatory upgrade to 3.<latest-version> then to 4.x?

i know @zero-24 did a PR (#12355) to check db versions on joomla update, maybe try to check if the utf8mb4 conversion is done too (using that table). Not sure if possible, just an idea.

Are we making utf8mb4 charset mandatory for 4.0? If not then we need to retain all logic that tells if the site has been converted or not and to convert the site if it moves to an environment where it is now supported.

Are we making utf8mb4 charset mandatory for 4.0?

not really my expertise. is there side effects in going that way?

Right now Joomla can operate in a mixed utf8/utf8mb4 mode (presumably others since our database drivers don't have hardcoded charset configs, but that's what the CMS uses). I wouldn't suggest locking down the code or schema to only support utf8mb4 personally.

ok. then we need to support the conversion in 4.0 too

The other thing to keep in mind is that also affects extensions' schemas. Even though our developer site is using utf8mb4 for the majority of its tables, I never updated one of our components on there to switch from utf8. And IIRC at one point the table's design was suggested to be done in a way that extensions could use it as a tracking table to determine if they'd been converted, but who knows anymore.

You are all missing the point.

Im not arguing for removing "tracking of conversion" - Im arguing that we don't, and should never have, had a single NEW database created for this purpose.

There is no reason Joomla needs a whole database table dedicated to this ONE feature of storing a SINGLE integer. Joomla has MANY other places this one integer can go!!

How about storing the conversion integer in the json params of the com_installer row in the #_extensions table? The Joomla Platform already does something like this with {"mediaversion":"49e45c9f3211821b34679bcadc01d4b6"}

I am missing the benefit of removing this working code and rewriting it to use a json value just to remove a single table. Plus you have to write new code to convert existing tables etc etx

It should never have been a one use, one row, one integer table in the first place - it was a wrong historic decision that I propose we put right instead of pulling baggage along for the next 10 years for the sake of maintaining the status quo....

Not all code changes are "for benefit" - some are for sound architectural and best practice reasons too, sometimes you just have to wipe up your mistakes and move on.

At most the whole proposed change would be less than 10 lines of code, probably half that..

It is not a single row table since it is supposed to be used by 3rd party extensions as well.
Imho, it makes no sense to change the code now as 3rd parties would have to adapt their code as well for no real reason.

And the documentation for third parties is where? and how many 3rd party extensions use it? Nil. Nada. Zip.

And like I said before, there is a good reason. Doing the right thing is a good reason. Dragging technical debt for years is a bad thing.

If you feel so strongly about it then please submit a PR

I don't waste my precious time on speculative PRs that have no chance of being accepted or sitting around for 3 years...

If the PLT want this change then they should say so and I'll do a PR right away else let's just all bury our head in the sand and let the technical debt grow....

#close

Sent from my iPhone

On 20 Oct 2016, at 00:00, Brian Teeman notifications@github.com wrote:

If you feel so strongly about it then please submit a PR

This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/12479.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

Sigh - once again you moan about code that you have the skills to resolve
but refuse to and instead continue to moan about it for ever.

On 19 October 2016 at 23:13, Phil Taylor notifications@github.com wrote:

I don't waste my precious time on speculative PRs that have no chance of
being accepted or sitting around for 3 years...

If the PLT want this change then they should say so and I'll do a PR right
away else let's just all bury our head in the sand and let the technical
debt grow....

#close

Sent from my iPhone

On 20 Oct 2016, at 00:00, Brian Teeman notifications@github.com
wrote:

If you feel so strongly about it then please submit a PR

This comment was created with the J!Tracker Application at
issues.joomla.org/tracker/joomla-cms/12479.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#12479 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8UXcPxa3HDLt7XbtOBEoJr8xM_mXks5q1qQwgaJpZM4KbMjw
.

Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

Whatever Brian. Personal attacks will not be tolerated. Fact is there appears to be no one else in support of this, so why should I waste my time in writing a PR for it to be rejected. Apparently requesting comment now is wrong too..