Jump to content

Will the database structure of PW 3 change until release?


steveooo
 Share

Recommended Posts

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.

Link to comment
Share on other sites

@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.

  • Like 5
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...