Pomm roadmap 2014 / 2015
47 views
Skip to first unread message
Grégoire Hubert
Aug 23, 2014, 8:58:06 AM8/23/14
to pommp...@googlegroups.com
Hello,
After 8 month of production, Pomm 1.2 is doing a great job. The more it is used, the more we receive ideas of improvements from developers across the internet.
Pomm 1.2.2 is to be released shortly and as you may know, it will not feature any new functionality but only bug fixes. There is somehow a question about adding the jsonb type to the JSON converter to the Database class in 1.2.2.
Pomm 1.3 is on track and already integrates some interesting new features. Recent developments with big databases with a lot of processes also showed that Pomm could be used in a more handy way. This would also require Pomm's internal structure to be reshaped and it would break compatibility from earlier releases which we must prevent at all costs. This said, Pomm 1.3 as third release of the 1.x branch will be an improved version of Pomm 1.2 and is felt to be available at the end of the year.
Pomm 2 will have the same philosophy but will be used in a slightly different way. Today's Pomm architecture makes the whole work to be done by two (fat) classes: "Connection" and "BaseObjectMap".
Connection will be split in at least two classes (possibly more): "Service" and "Connection". The "Service" class will be the place for developers to describe business oriented operation in transactions and to call queries from "EntityMap" methods. It still will be possible to directly call "EntityMap" methods from controllers but complex business rules require a service layer.
"BaseObjectMap" will also be split. It will no more hold the structure nor the queries but will only handle the Projection and the hydration processes.
Today's projection system is simple (and efficient) but it could be more flexible if projection were object as well. This way, it would be easier to manipulate the projection in adding or removing fields and managing aliases.
The way the conversion is done today is one of the biggest Pomm's strength. Still, it is often akward to declare virtual fields to trigger conversion on some fields. Pomm 2 will feature an "HydrationPlan" that one will pass as query argument to tell Pomm how to hydrate the result.
Aside of this new organization, Pomm 2's code standard will change to follow the present PSR standard and if we do good, it might be available in late 2015.
Remarks or suggestions are welcome.
Cheers,
Grégoire
After 8 month of production, Pomm 1.2 is doing a great job. The more it is used, the more we receive ideas of improvements from developers across the internet.
Pomm 1.2.2 is to be released shortly and as you may know, it will not feature any new functionality but only bug fixes. There is somehow a question about adding the jsonb type to the JSON converter to the Database class in 1.2.2.
Pomm 1.3 is on track and already integrates some interesting new features. Recent developments with big databases with a lot of processes also showed that Pomm could be used in a more handy way. This would also require Pomm's internal structure to be reshaped and it would break compatibility from earlier releases which we must prevent at all costs. This said, Pomm 1.3 as third release of the 1.x branch will be an improved version of Pomm 1.2 and is felt to be available at the end of the year.
Pomm 2 will have the same philosophy but will be used in a slightly different way. Today's Pomm architecture makes the whole work to be done by two (fat) classes: "Connection" and "BaseObjectMap".
Connection will be split in at least two classes (possibly more): "Service" and "Connection". The "Service" class will be the place for developers to describe business oriented operation in transactions and to call queries from "EntityMap" methods. It still will be possible to directly call "EntityMap" methods from controllers but complex business rules require a service layer.
"BaseObjectMap" will also be split. It will no more hold the structure nor the queries but will only handle the Projection and the hydration processes.
Today's projection system is simple (and efficient) but it could be more flexible if projection were object as well. This way, it would be easier to manipulate the projection in adding or removing fields and managing aliases.
The way the conversion is done today is one of the biggest Pomm's strength. Still, it is often akward to declare virtual fields to trigger conversion on some fields. Pomm 2 will feature an "HydrationPlan" that one will pass as query argument to tell Pomm how to hydrate the result.
Aside of this new organization, Pomm 2's code standard will change to follow the present PSR standard and if we do good, it might be available in late 2015.
Remarks or suggestions are welcome.
Cheers,
Grégoire
Reply all
Reply to author
Forward
0 new messages