Published version not really published? Bug?

Anvil Q&A
1

Background:
I got an error when I tried to load an app serves some content based on the hash in the url:
TypeError: ‘NoneType’ does not support indexing
at CleanFront, line 47

After identifying the bug, I try to publish a new version, but the “publish” sign does not move. It stays like this:

Screenshot of scast _ Anvil Editor
Screenshot of scast _ Anvil Editor1272×310 83.6 KB

Now, as usual I suspect that I am doing something wrong, but in this case there were some clues that maybe - just maybe - something else might be going on.

Because: The logs of the app did not show my new (failed) attempts to load the content. No errors (and no successful events) in the log (yes, refresh). And I still god the same error (which I should not have gotten in the updated version).

Context:
It is an old app, that has been updated from the classical version, to the new editor, and the url has changed several times. The publish page also says the app is available at some legacy URLs. It also contains some shared tables that stopped working and had to be corrected (schema issues).

2

A partial answer: It seems like when we save to a shared table from different apps, the unique id referring to the row is different depending on the app (Was this always the case? I did not have the current problem previously?)

When I try to fetch a row using get_by_id(id) based on the id that I got from saving the row the first app, this does not work.

Probably not a bug. But good to know that table rows ids are not “transferrable”?

1 Like
3

I tested out accessing a shared table from two different apps just now (using the super-helpful server repl) and I get the same id for a given row in both. So I’m wondering if there’s something else going on in your case?

4

This implies that the table is no longer shared. You may want to double-check it.

5

If it’s an old app, I assume you are “resetting” rather than “merging” the branches.

If that is the case, then you can double click on the published branch, then right click on the master and reset 'published' branch to here.

I often have problems when I put my hands on old apps. So, instead of trying to keep it working as it used to work, I always click the Publish button and create two environments linked to two branches. I call the two environments Production and Development and make sure the Production is configured with the correct url. From this point on, in simple apps where production and development are identical, which is the case in most old apps where I didn’t have the flexibility of today’s environments, I reset the prod branch to the dev branch rather than merging. In apps where the development has some different settings, like scheduled tasks configuration or email in test mode, I merge dev into prod.

The old workflow based on the Publish button was very simple and rigid, but was working great with the old editor.

The new editor is much more powerful, but it’s confusing. There still is a branch called master, but its meaning has changed. The Publish button used to create a published branch, but it doesn’t do that any longer. The behavior and the publishing workflow changes depending on how the app was setup in the Publish this app dialog.

The old editor had a very clear and intuitive workflow. The new is messy non intuitive and inconsistent. The branch called master can’t be renamed, but nobody knows what it does. Some use it as development, some as production. The Publish button does something, but who knows what (hence your question). After each merge, the UI checks out another branch without asking or warning you.

Think of a world where a new app starts with two branches, one called development and one called published, and where developers can rename any branch. In that world people would know which branch is for development and which one is for production, and they could even rename them however they like, including a phantomatic master.

(Sorry, this morning I woke up in rant mode)

6

Yes, good catch. Visually they appear to be linked (icons), but in fact schema bugs seems to create problems since storing from one app, does not make it appear in the datatable for the other app. Strange problems like these keep popping up when using old apps and messing around, but I live and learn. Thank you!

7

No need to be sorry. Secret: I realize that the new git-like publish/commit/branch/merge etc is more flexible and powerful, but I have also - on several occasions - had some internal rants about the complexity and added cognitive burden of the new system. Not so much the editor, but the storing/publishing process. The old store/publish/version (ui and process) was very simple and easy to understand.

1 Like
8

I agree!!

The new one could have a starting configuration as simple to understand by simply having:

  • 2 default branches named development and production (I just can’t stand that master)
  • 2 default environments Development and Production linked to them
  • a Reset production branch here button that resets the production branch to the development…
  • …without checking out production (this is the most important thing, it’s how the old UI was working, it was great, and they changed it for no (apparent to me) reason)

Some advanced options:

  • branches should have a read-only option, so one doesn’t risk to edit production code
  • the Reset production branch here should show the name of the branch linked to the main environment, and the main environment is the one with a checkbox that says so in the environment configuration page. This would allow both the simple, easy and intuitive behavior on a new app to be consistent with whatever configuration any complex app could have
  • other buttons to manage the merge, or perhaps a setting that changes the default Reset production branch here into Merge into production branch (I either use the reset on very simple apps or the merge on most less simple apps, I never use both in the same app, so perhaps having either one or the other button is better than having them both always there, confusing you)

Please make those rants public!
The Anvil team keeps their eyes on this forum, and they do listen to us pretty often… unless we keep our rants for ourselves :slight_smile:

9

Update:

  • As @hugetim and @p.colbert suggested, something was off with the link between the tables. Deleted (all three) and relinked. Still had some issues. Seems like one also has to (manually) make sure that the permissions are the same (search/write from client or not). Slightly unsure why it happened in the first place. Maybe, maybe turning on accelerated tables in one app, but not the other, might create some problems with tables shared across apps.
  • The publishing thing is a separate issue, as explained by @stefano.menci. New procedures, new habits needed - even for old dogs!

Hans Olav

1 Like
10

Seems quite plausible to me. Sounds like a brand new Q&A topic!

1 Like