maritz
maritz
Sorry, I'm sick right now, my brain doesn't work quite right. The documentation is clearly missing that as well.
Yep, you are right. It's a problem with the `.id = ` thing I suggested to you in the other issue (#140). The "idsets" sets are not filled this way....
The methods affected by this bug are: `find`, `sort` and `exists`.
This should be normal behaviour. In the current implementation there is a step before validation and saving that makes this negative timestamp ID if the model is new. This is...
No, there is something wrong and needs to be fixed. But I'm glad that you found a workaround for now. :+1:
After re-reading it all and thinking about it a bit more, this is both a bug in your usage and a problem in nohm. So the reason it produces a...
Maybe something like "typeAsNumeric" that adds a step after typecasting as well to additionally type the return of the behaviour to int/float. This is especially useful for fields like createdAt...
Hope that clears it up. ;-)
Nohm is not built to be completely transaction safe at its current state. So far this hasn't been much of a concern for me, but if there is enough demand...
AFAICT there is no way to do this without either breaking a lot of other functionality or doing some semi-complex "manual" cleanup and still risk breakage.in some cases. The problem...