You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to avoid db-specific code for simple logic, and am sure many others feel the same way;
If there was a way to pass a lithium\data\type\DateTime object to model operations and automagically convert it to MongoDB\BSON\UTCDateTime for Mongo and string for MySQL,
That accomplishes the goal. Comparison operator translations for most types are already provided in the Db adapters so this is just another step in that direction. Tentatively, the proposed types are:
DateTime Timestamp Geometry (spatial) Point (spatial)
Need to add a 3-4 operators for the spatial types in each Db adapter (within, intersects, near, and maybe nearSphere sphere), but I think this is a pretty simple and effective concept.
Here's an example for a spatial type:
// Find all people within 100m of {{ $coords = [0.9876543, 255.12345] }}// Works the same for Mongo, MySQL, etc.use \People\models\People;
use \lithium\data\type\Point;
People::find("all", [
'conditions' => [
'spot' => ['near' => compact("coords") + ['min' => 0, 'max' => Point::metres(100)]]
]
]);
This could perhaps be facilitated by merging/refactoring essential components of the li3_geo plugin and making it unnecessary for simple use cases. Thoughts?
I'd like to avoid db-specific code for simple logic, and am sure many others feel the same way;
If there was a way to pass a
lithium\data\type\DateTime
object to model operations and automagically convert it toMongoDB\BSON\UTCDateTime
for Mongo andstring
for MySQL,That accomplishes the goal. Comparison operator translations for most types are already provided in the Db adapters so this is just another step in that direction. Tentatively, the proposed types are:
DateTime
Timestamp
Geometry
(spatial)Point
(spatial)Need to add a 3-4 operators for the spatial types in each Db adapter (
within
,intersects
,near
, and maybe nearSpheresphere
), but I think this is a pretty simple and effective concept.Here's an example for a spatial type:
This could perhaps be facilitated by merging/refactoring essential components of the
li3_geo
plugin and making it unnecessary for simple use cases. Thoughts?Ping @DavidPersson @nateabele
The text was updated successfully, but these errors were encountered: