I just signed up for the forum to discuss the 1.0 version.
I don’t want to be a downer only a third of the way through the book, but I think so far working through it with Phoenix 1.8.5, a lot of the writing doesn’t seem to be fully updated to match the current generators. It seems more like certain paragraphs were added to cover changes, but the main body of writing is still referring to an older design for LV.
could you give an example or which page(s)?
Yes. It’s page 114 through 133. Technically, paragraphs were added to acknowledge 1.8 updates, but there’s still parts on push_patch that aren’t reflected in the current generator anymore.
EDIT: Reading forward, I see a section telling me to use .simple_form which is no longer in core components.
This could be good case for an errata
Another example would be in Chapter 3 on p84 the changeset example showing product.ex requires a user_scope to be passed in but the example in “Test Drive the Schema” showing the usage within IEX does not show the establishment of the session nor includes it in the creation of the sample changeset shown on p85.
There are actually a number of errors in the the ‘Final Edition’ most are pretty easy to get around but I have just started in Chapter 3 and there seems to be a mix both of generator versions and actual data used. Using Phoenix 1.8.5 there appear to be are versions of the product table which have a user_id column and versions that don’t. Also when following the steps in the book the resulting functions do not include a changeset/2 the closest is a changeset/3 which referenced the user_scope. This is very frustrating and hopefully will be addressed in a new edition. I tried changing to an earlier version to see if that would resolve the problems and it does to some extent but it results in some aspects of the book, so far, not making sense.
Referencing my earlier post it appears that the one distinction may be that the default behavior of the phx.gen.live automatically add uiser scope when the auth has been generated. This not discussed at all in the book that I can find but it is relevant because there is a --no-scope option the does not add the user scope and there is then a changeset/2 instead of a changeset/3. It would appear that either the generator that existed at the time the books content was created either did not add the scope or the --no-scope option was used in part of the testing. As a practical matter under normal circumstances why would you ever want a user id to be a foreign key for a product table? Maybe to knwo who created it but would you actually want to delete the product record if the user was deleted?
Remember that the generators don’t know your domain, in this case the products. They are assuming by default that all data created through a certain user scope will only ever be owned by that user, i.e. only they can observe the data, only they can make modifications to the data, and finally if the user is deleted then all that data is cleaned up since they are within the user’s “scope”.
These are good authorization defaults. The bigger problem is more to do with how the book doesn’t really bring that up.
I don’t disagree - I made the mistake of trying to make two point at once. The more important point is that the book does not address the --no-scope option for the generator. The less important point was made to imply the importance of describing the option, that being that as a practical matter ‘product’ implies something that would be bought, sold or inventoried. In most practical systems you wouldn’t want to delete records of product that had been bought, sold or inventoried simply because the user that created it had been deleted. I didn’t mean to imply it wasn’t a valid example of the generator’s functionality.
Also when working through Chapter 3 it is clear there are instances where the product schema / data included the user_id foreign key/constraint and other places where it didn’t - re: changeset/2 as an example.
Thanks for your comment.
