Tharos
commented
10 years ago Well, I'm not sure this is a good idea. The main problem is that I don't know exactly how people use Lean Mapper.
On one my tiny website I use Lean Mapper as a very very simple ORM: I don't use mapper in filters, I write custom low-level SQLs in repositories etc. Using Lean Mapper still make sense to me on that website since it checks data types, I can use entites as type hint so I can rely on their API… But I wouldn't use Lean Query on that website because I just don't need it.
I guess that many people use Lean Mapper this way and they might not appreciate merging Lean Mapper and Lean Query. It's just better to have only the code you really use in your vendor directory.
You can use Lean Mapper in many different ways and I find that as a big advantage of it. One programmer can use generic DAOs, one can prefer concrete repositories, one can prefer Lean Query…
If most users prefered Lean Query I would probably merge it. But I just don't know their preferences.
Using Lean Mapper and Lean Query together will be trivial when finished. I'd like to make some useful traits you could use in your base repository and base entity very easily.
Hello, would you consider merging the two projects? There are several reasons. First LeanMapper is an ORM. That by definition says that it maps object to relation db. I expect ORM allows me to query objects by their properties. Translation to sql is lower level and should be done by ORM solely. LeanMapper is in my opinion incomplete without this feature.
The other reason is that if merged there could be a method in repository returning preconfigured domain query. Ex. createQuery($alias). Of course the method could exist even without merge but that would require two-side dependency between the projects which I think would look silly.