| [20:06:15] | * generalredneck[m has quit (*.net *.split) |
| [20:06:17] | * jcalonso[m] has quit (*.net *.split) |
| [20:08:37] | * pllagn[m] has quit (*.net *.split) |
| [20:08:37] | * aislinnpearson[m has quit (*.net *.split) |
| [20:08:37] | * wombat83[m] has quit (*.net *.split) |
| [20:08:37] | * skalakm[m] has quit (*.net *.split) |
| [20:08:37] | * enhiguy[m] has quit (*.net *.split) |
| [20:08:37] | * JulianF has quit (*.net *.split) |
| [20:08:37] | * calbasi_matrix has quit (*.net *.split) |
| [20:08:37] | * mmn has quit (*.net *.split) |
| [20:08:37] | * Kingdutch has quit (*.net *.split) |
| [20:08:37] | * sydney_zimbotech has quit (*.net *.split) |
| [20:08:37] | * braught[m] has quit (*.net *.split) |
| [20:08:37] | * symbioquine[m] has quit (*.net *.split) |
| [20:08:37] | * dazinism has quit (*.net *.split) |
| [20:08:37] | * svenn has quit (*.net *.split) |
| [20:08:37] | * lauriexwayne[m] has quit (*.net *.split) |
| [20:08:37] | * zedrickr11[m] has quit (*.net *.split) |
| [20:08:37] | * jgaehring[m] has quit (*.net *.split) |
| [20:08:39] | * mstenta[m] has quit (*.net *.split) |
| [20:08:39] | * paul121[m] has quit (*.net *.split) |
| [20:08:39] | * kunigunde[m] has quit (*.net *.split) |
| [20:09:29] | * jcalonso[m] has joined #farmos |
| [20:09:29] | * generalredneck[m has joined #farmos |
| [20:09:29] | * svenn has joined #farmos |
| [20:09:29] | * sydney_zimbotech has joined #farmos |
| [20:09:29] | * braught[m] has joined #farmos |
| [20:09:29] | * lauriexwayne[m] has joined #farmos |
| [20:09:29] | * zedrickr11[m] has joined #farmos |
| [20:09:29] | * jgaehring[m] has joined #farmos |
| [20:09:29] | * wombat83[m] has joined #farmos |
| [20:09:29] | * pllagn[m] has joined #farmos |
| [20:09:29] | * symbioquine[m] has joined #farmos |
| [20:09:29] | * mmn has joined #farmos |
| [20:09:29] | * skalakm[m] has joined #farmos |
| [20:09:29] | * mstenta[m] has joined #farmos |
| [20:09:29] | * aislinnpearson[m has joined #farmos |
| [20:09:29] | * enhiguy[m] has joined #farmos |
| [20:09:29] | * paul121[m] has joined #farmos |
| [20:09:29] | * JulianF has joined #farmos |
| [20:09:29] | * kunigunde[m] has joined #farmos |
| [20:09:29] | * dazinism has joined #farmos |
| [20:09:29] | * calbasi_matrix has joined #farmos |
| [20:09:29] | * Kingdutch has joined #farmos |
| [21:37:38] | * farmB877 has joined #farmos |
| [21:38:10] | * farmBOT has quit (Disconnected by services) |
| [04:00:06] | * aislinnpearson[m has quit (Quit: Idle for 30+ days) |
| [11:16:29] | <mstenta[m]> | ah gotcha - yea so we may want to provide a helper for that - i think we'll need it elsewhere in core as well |
| [11:18:02] | <symbioquine[m]> | How does it work with Views? Does filtering on computed fields just happen in the PHP layer? |
| [11:18:19] | <symbioquine[m]> | ... I guess it must. |
| [11:23:19] | <mstenta[m]> | We don't have Views filtering wired up yet - we do have the Views field working, but yea that performs additional PHP to get the entity |
| [11:23:32] | <mstenta[m]> | for filtering we will need to add a custom filter handler |
| [11:23:37] | <mstenta[m]> | similar to what we had in 1.x |
| [11:24:19] | <mstenta[m]> | in 1.x we had a query builder specifically for building the location query, which was used by BOTH the views handlers AND the "entity property info" (which became the unified field system in D8) |
| [11:24:30] | <mstenta[m]> | so it's a work in progress :-) |
| [11:25:56] | <mstenta[m]> | in D9 i think we'll probably provide an additional service that extends the `log.query` service and adds the conditions we want to the query |
| [11:28:19] | <symbioquine[m]> | I guess for now I'll prototype by making the query using the lower-level SQL API and switch to that extended log query service once it's available :) |
| [11:28:24] | <mstenta[m]> | although -- we are mainly concerned with `location` for the filtering we need... not `geometry` |
| [11:28:47] | <mstenta[m]> | `location` is a bit simpler because if `fixed==true` then location is always empty |
| [11:28:54] | <symbioquine[m]> | ah, that makes sense |
| [11:29:30] | <mstenta[m]> | `geometry` is tricky and may be hard to represent in a single query now that i think about it |
| [11:29:34] | <symbioquine[m]> | But you'd need the geometry filtering if you want to be able to implement that "draw a box to find the assets" kind of functionality... |
| [11:29:37] | <mstenta[m]> | for your purposes you may want to have two queries - one for fixed assets and one for non fixed |
| [11:29:46] | <mstenta[m]> | right |
| [11:30:26] | <symbioquine[m]> | <mstenta[m] "for your purposes you *may* want"> Yeah, I thought about that... start with the logs which match the given geometry and have asset references |
| [11:31:21] | <symbioquine[m]> | That could work with the WFS 1.1.0 since it doesn't implement proper pagination, but for later WFS versions it could get pretty expensive to need to do that pagination in the PHP layer... |
| [11:31:27] | <mstenta[m]> | and that sort of makes sense (to have two queries) because you are actually querying two different tables... (logs and assets) |
| [11:32:58] | <mstenta[m]> | 1.x was just one table but that was only because the same `field_farm_geofield` was allowed to be used on both logs and taxonomy terms (areas). In d8+ field definitions are entity-type specific... |
| [11:33:20] | <mstenta[m]> | (i'm not sure why, but i bet there's a good reason) |
| [11:34:37] | <mstenta[m]> | so yea... i think in order to query asset geometry directly (without using the `geometry` computed field on assets), we'll need BOTH a query of `log__geometry` to get movements AND a query of `asset__intrinsic_geometry` to get fixed asset geoms |
| [11:36:10] | <symbioquine[m]> | <mstenta[m] "1.x was just one table but that "> That seems good, but it doesn't necessarily imply that it's better to make two queries. Joining both the intrinsic geometry and the relevant log-derived geometry with the asset data as part of a single query allows the pagination to happen at the DB layer instead of needing to collate the results from two queries in the PHP layer. |
| [11:36:26] | <mstenta[m]> | yea that's true |
| [11:37:07] | <mstenta[m]> | it can certainly be done with a single, albeit less simple, query :-) |
| [11:38:33] | <mstenta[m]> | just need the right combination of `JOIN`s and `WHERE` conditions with an `OR` to catch both the fixed and moveable assets |
| [11:39:37] | <symbioquine[m]> | yeah |
| [11:39:46] | <mstenta[m]> | (maybe a subselect would be needed too - i'd need to try it out) |