But.. why? How does this perform compared to Mongo or using plain SQL? The repository pattern is the correct solution for this by placing an abstraction above the database implementation. In that why you can switch over to another /use fake implementation for testing rather than forcing a NoSQL conform API over MySQL. This stuff indeed sounds interesting, but I really hope you don't plan production usage of it.
There are definitely use cases for using this implementation. Why is it okay for Doctrine to exist and that’s perfectly acceptable for a production application, but a library like this is poo pooed on?
Seems to me like just because you might not find a production application for a library like this doesn’t mean someone else might find it useful for their application. And the opinion you shared certainly doesn’t invalidate FireSQL as a valid solution.
What is the use case for this implementation? I don't like SQL/I don't know how to write effective SQL queries but I have to use it anyways, therefore I will use a NoSQL like API with whatever under the hood because it looks nicer to me?
Doctrine and all the ORMs will also fail when you have really complex queries and causes unnecessary headaches/overhead.
As I said this project is still interesting and I am curious about the implementation but also about the performance. Create a real life project to prove its worthiness. Do some performance tests compared to a native SQL or Doctrine project. Before that I feel dangerous to say it's a valid solution.
What if a newbie comes in from the Mongo/JS world, and says "finally, I hate SQL, let's use this", and when he ends up in a SQL heavy company, he will suck because they won't let him to use a solution like this or maybe he will start using it and it turns out that this stuff is damn too slow.
We need to be very careful about what do we show to the junior colleagues because any bad practice, misused tool might ruin their days, weeks or even their career.
I think I failed to mention that FireSQL comes with a demo and a library called FireBug. Firebug makes it possible to track all queries being made to the database, how long it took for each query to run and gives you the ability to peer into what's going on behind the scenes.
I could demo this if anyone wants to jump on a Google Hangout some time.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
But.. why? How does this perform compared to Mongo or using plain SQL? The repository pattern is the correct solution for this by placing an abstraction above the database implementation. In that why you can switch over to another /use fake implementation for testing rather than forcing a NoSQL conform API over MySQL. This stuff indeed sounds interesting, but I really hope you don't plan production usage of it.
There are definitely use cases for using this implementation. Why is it okay for Doctrine to exist and that’s perfectly acceptable for a production application, but a library like this is poo pooed on?
Seems to me like just because you might not find a production application for a library like this doesn’t mean someone else might find it useful for their application. And the opinion you shared certainly doesn’t invalidate FireSQL as a valid solution.
What is the use case for this implementation? I don't like SQL/I don't know how to write effective SQL queries but I have to use it anyways, therefore I will use a NoSQL like API with whatever under the hood because it looks nicer to me?
Doctrine and all the ORMs will also fail when you have really complex queries and causes unnecessary headaches/overhead.
As I said this project is still interesting and I am curious about the implementation but also about the performance. Create a real life project to prove its worthiness. Do some performance tests compared to a native SQL or Doctrine project. Before that I feel dangerous to say it's a valid solution.
What if a newbie comes in from the Mongo/JS world, and says "finally, I hate SQL, let's use this", and when he ends up in a SQL heavy company, he will suck because they won't let him to use a solution like this or maybe he will start using it and it turns out that this stuff is damn too slow.
We need to be very careful about what do we show to the junior colleagues because any bad practice, misused tool might ruin their days, weeks or even their career.
I think I failed to mention that FireSQL comes with a demo and a library called FireBug. Firebug makes it possible to track all queries being made to the database, how long it took for each query to run and gives you the ability to peer into what's going on behind the scenes.
I could demo this if anyone wants to jump on a Google Hangout some time.