I was a big fan of metabase (to the point I deployed it in 4 companies and rolled it out for many people to use in their daily workflow). All was nice.
Somewhere around 0.31 something changed in the internal dev/release flow. I get the feeling they have some kind of internal push to add unnecessary untested features which all look nice on paper, and work on a 5-row 5-column user tables. Until you actually use those features and all functionality fails miserably..
Had weird issues with it, which usually occurred after upgrades, on both small and bigger decently indexed DB's (pg and mysql), things like:
- had sets of reports which all worked fine until they hit a 1001 rows.. and suddenly the UI had a react race condition.
- X-Rays which silently fail and break the UI, while on the DB server you see the queries complete.
- Deployed new versions which would hammer databases by distincting every column individually every hour, instead of handling statistics a bit more intelligently. Disabled that ofcourse.
- Deployed versions in other countries, where the UI client-server latency caused the whole UI to break (probably the limits of setTimeout reached? :-)).
If you check the github issues, it's just ignored problems and they are focus on releasing new functionality instead of fixing the issues. Doesn't really motivate to report anymore problems.
They had one good thing: they would allow you to work in sql and write efficient queries, but clearly they decided it's time to remove the last good feature and now only want graphical query builders.
If you use metabase: deploy it on a replica such it doesn't whack your prod DB. And take backups before upgrading, because there is no revert.
I've spent enough time on Metabase problems, won't touch it anymore.
I’ve taken a quick glance and looked at the code. It’s a Java/Spring Boot project which usually gets a lot of flak around here for “too much magic”.
This project is written in a very clean style and seems to use a minimum of Spring. Mainly rest controllers, configuration and and dependency injection. No hibernate/orm or AOP stuff.
This seems to be listed as a feature, which I find confusing. Not everything lives in SQL databases. Some things you extract for example from external APIs.
Is this basically "this is out of scope for the project", or it's a feature because we've got <alternative>?
This is even worse in 3d pie chart which doesn't even preserve proportions in areas/angles, so splitting in 4 parts, bottom/top will be larger than left/right.
I got it up in a few hours, and the included docker (compose) files are helpful, but it was a frustrating experience for a couple of reasons:
* There is some legal issue with the Apache foundation that’s preventing them publishing to PyPi (details about this were lacking).
* As a result, the provided dockerfile uses a very outdated version.
* Installing any missing dependencies means essentially building your own dockerfile anyways: in my case, it was the bane of my life Snowflake DB dependencies...
* Maybe it’s just me, but figuring out how to go from single-container ephemeral deployment to backend celery workers, external DB for persistence and a redos instance for caching (the recommended production setup) was frustrating to no end
* There are hosted versions you can use.
That said, we’re still going ahead with Superset, because it’s an improvement over the costly, ugly and over-opinionated alternative that is Tableau...
What is the story behind Poli?
