Will the database structure of PW 3 change until release?

[steveooo]

Hello,

will the database structure change until stable release of ProcessWire 3 or won't the database be touched?

This would be great to know, Ryan!

[Pete]

It won't change in any way that will affect you. Since everything is abstracted via the API one of the best things about ProcessWire is that Ryan could rename all the database tables to nonsensical names but as long as it's tied back to the API correctly all the same API calls will still work fine.

[LostKobrakai]

@steveooo

This question was already answered in your previous thread by quoting the README of ProcessWire 3, which is written by Ryan. It seems to me you're not really trusting the answers even of our best community members. You won't always get answers directly from Ryan, as he's quite aware and sensible about how much time he's able to invest into reading/writing here and most of it goes into VIP support of his pro modules and the really important topics like bugs or other critical topics.

[steveooo]

You get me wrong. These were 2 different question. The answer in the README of PW 3 tells that until now, the database did not change.

Here I am asking if the database will (future) change until release.

2 different questions.

[diogo]

ProcessWire 3.x doesn't make changes to the database, so the database should be identical between 2.7 and 3.0.

I guess your problem with the sentence in the readme is the word should. Ryan was already explicit in saying that he believes that the devns branch is safe for new projects, even the download button in the site states that: "The newest 3.x dev version, great for testing, new projects or development." Honestly, if these aren't enough for you, maybe you should play safe and stick to the stable branch.

[LostKobrakai]

There's really not much "fixed" db structure to change anyway. There are about 9 tables, which are installed by default and are not dynamically setup. They handle the data of templates/fields/pages (name, status, hierarchy; not field data) and modules and there's a cache table. These are very unlikely to change in a way to not be backwards compatible. Any other tables are created by fields you're creating in the backend or by some modules.

So any changes in the database, which would not be backwards compatible are from fieldtypes or other features, which are explicitly stated as 3.0 only. If you're using those there might be no way back. For example the new repeater field is one of those changes, which didn't need database changes, but still the UI for hiding repeaters is only available in 3.0. So you shouldn't rely on that feature, even though there where no changes to the db, but rather on how the available fields are used.

But I'm totally with diogo. I don't see much reason to use 3.0 if you're such concerned. There's essentially no benefit if you're not using new features beyond maybe helping Ryan with reporting issues.

[steveooo]

@LostKobrakai: I like your answer very much but I had to mark diogo's answer as "Solved" and not yours. But thanks for this answer! This helped a lot!

Edited February 21, 2016 by LostKobrakai
Fixed my name :D

[diogo]

I think @LostKabrakai doesn't mind

[steveooo]

Ooops..