abaldwin99

Here's the example I point people to when talking about transactions: https://sakurity.com/blog/2015/05/21/starbucks.html

I have to admit I'm getting a bit of fatigue reviewing frameworks in Node that are claimed to be batteries-included and similar to Rails/Django/Laravel. SailsJS, Redwood, NestJS, Remix, Prisma (ORM compared to Active Record). They all have an exciting landing page, clean looking documentation... but once you dig in further the feature set starts looking very <= Rails v1.0.

Anyways I appreciate the name drop of Adonis. I'll have to give it a fair shake when I'm not feeling quite as cynical because I _really_ do want to find a solid Node framework in this area.

Some of these newer frameworks are certainly using the term "full stack" in a very different sense than how it's been used historically. Could you fault someone for a cursory reading of the homepage and coming away thinking that Fresh/Remix do all the features you listed out of the box?

There's enough confusion here I suppose I'll start using the term "batteries included framework" for the technologies you listed.

At some point I want to write a long-form post with code proving my statements above. I walked through this scenario a long time ago using https://www.flopzilla.com/holdeq.html to find the equilibrium but it'd be neat to write open source code that does the number crunching and that way others could actually audit the proof.

The short of it though is there exists a perfect range of cards the bot can play where it neither folds enough for you to bluff to gain an edge, nor does it call enough that you can wait for better cards while bleeding chips to gain an edge.

If the bot is playing a Nash equilibrium then it doesn't need to devise the opponent's strategy. It's guaranteed to tie the opponent in the worst case (the opponent is also playing Nash equilibrium) or else win.

https://en.wikipedia.org/wiki/Nash_equilibrium

However, if the opponent is playing sub-optimally you can win _more_ by deviating from Nash equilibrium to take advantage of their specific strategic shortcomings. The risk in doing so is if you are wrong estimating their shortcomings.. you are no longer guaranteed a tie in the worst case scenario.

You can see this play out with a small toy game and a card calculator. Suppose a two player game of Texas Holdem where each player has 8x big blinds. The first player must choose to either go all in or fold. The second player must choose to either call the all in or fold. Players must pick a range of hands to perform either action prior to looking at their cards.

https://openpokertools.com/range_equity.html

Suppose a silly strategy by the second player of folding any hand except pocket aces. You'd be wise as the first player to go all in with any hand and pick up a free big blind with 99.5% certainty. However going all in with every hand is also an easy strategy to take advantage of...

(You can actually go back and forth maximally exploiting the other player's strategy and you will eventually reach Nash equilibrium)

The difference for poker is it takes a lot more play time to sort players by skill. There's no ELO to climb and thus you don't get to play against more challenging opponents.

e.g. I'll lose 100% of my matches against a Chess GM but against the best poker player in the world I could go all in preflop every hand and still win the match ~20% of the time.

Only way to counter this variance is to play lots and lots of hands (Law of large numbers) It could take weeks/months in a single matchup to determine the better poker player.

In terms of playing for real money, in general you'll find more challenging competition at higher stakes. But then there's an incentive for bots.

Ditto

Sure we do that before every release as well. But a rollback is a much less invasive surgical fix compared to a full database restore. You're down while the new db instance spins up and any writes in the meantime will be lost.

You can also test migrations against a restored prod database snapshot but again there's no guarantee some incompatible data hasn't been inserted in the meantime.

So future features notwithstanding, is the typical Prisma workflow that if a migration failed during a production deploy the developer would have to manually work out how to fix it while the application is down?

Thanks for getting back to me!

Most of these are pretty important to us. I did try to put lower priority items near the bottom of the list. However, I did omit several nice-to-haves already. e.g. ActiveRecord's ability to diff changes after an update (ActiveModel::Dirty)

I wouldn't say any of them are complete full blockers by themselves but cumulatively yes they prevent us from considering Prisma for most projects.

@nikolasburk can you comment? Before compiling this list I was seriously considering using Prisma to kick off a big upcoming project. In the spirit of being open-minded I'd really like to know if I'm fundamentally misunderstanding Prisma capabilities.

I'm completely perplexed at some of the functionality that's absent in Prisma? I'm coming from the Rails/Django world for reference. Can anyone help me understand if I'm out in left field or does this technology only cover basic use cases?

  - No supported way to do a case-insensitive sorting.  https://github.com/prisma/prisma/issues/5068
  - Can’t sort by an aggregate value like user’s post count. https://github.com/prisma/prisma/issues/3821
  - Can’t control between inner/left join.
  - Can’t do subqueries.
  - Migration rollbacks are experimental maybe unsupported now? At least I only see mention in Github issues and not in the docs.
  - Transactions appear to expect a series of queries? It doesn’t look like you can execute any app code during a transaction?
  - No support for pessimistic row locking e.g. SELECT… FOR UPDATE ?
  - No way to mixin raw query partials like `where('name ILIKE ?')`. You either need to write the whole query raw or not.
  - Validations are done at the database level.
    - Complex validations seem tricky to write in this format
    - No built-in way to make clean user-facing validation messages.
    - You can’t check that a model instance is valid without just trying to insert it into the database
  - The official documented validation example has you connecting via psql and adding a constraint?
    - So following the offical example my validations aren’t documented in the codebase via a model or a migration? 
    - Also they don’t have a validation example documented if you’re using MySQL instead of Postgres?
  - Cascading deletes are handled the same way as validations. As in Prisma basically does nothing other than document how to implement it yourself outside of the library.
  - No model methods. I guess that's not a surprised because it's "not an ORM". A model really is just a data mapping? Anyways it seems like you would end up rolling your own wrapper around this and there's no recommendations on standardized architecture.
  - No callbacks. These have been controversial at times so are teams using Prisma writing something akin to "services" instead?
  - Syntax nitpick but one of these is vulnerable to a SQL injection and it seems really easy for a new developer to get mixed up?
    - prisma.$queryRaw(`SELECT \* FROM User WHERE email = ${email}`);
    - prisma.$queryRaw`SELECT \* FROM User WHERE email = ${email}`;
  - No way of batch loading like Active Records’s find_in_batches / find_each. All objects are just loaded into memory?
  - No way of hooking into queries for instrumentation. e.g. ActiveSupport::Notifications.subscribe

FYI - This is after fairly brief research. Not guaranteed 100% accurate.