Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
Yep, I've been forced to do something similar. SharePoint is generally a trashfire that even the odata interface can't compensate for.
If you need a db, just use a db 😆
*disgusted, mortified face*
Well. Greek mythology had echidna, the mother of all monsters.
Guess you did a pretty good job of implementing her modern equivalent in the 21st century.
I've seen my fair trade of insanity.
I guess reinventing a DB isn't joyful.
That's what you did.
Afaik Sharepoint has no transaction support, so in a nutshell you must have invented some kind of (semi-) transactional system that wraps SharePoint. Your caching is a part of that.
And yes... Handling a process state on a shared resource without transactions or ACID isn't fun.
Lot's of brain damage.
@IntrusionCM 😂😂 You're not wrong at all unfortunately. It's funny that you mention transactions, because it's absolutely been asked up more than once (both by my team members and the client) if we can implement an ACTUAL transaction-esque system to our... System. Luckily we've been too swamped with other stuff to give it much attention...
It's a stupid (but stupidly lucrative) project ¯\_(ツ)_/¯
Well... Some APIs are amazingly talented at fucking up error handling.
So at least a bonus point if that works without having to double check or doing weird shit *TM.
I remember in this context (sorry for hijacking the rant) one internal API in that company that did the following (REST based):
- fetchResource returns 200 always
- response contains an UUID
- call fetchResourceStatus API with UUID to get the result set
- call fetchResourceError API with UUID to get the error
A very special person was very proud for his "absolute clear and intuitive design".