| [00:29:57] | * DanielAshcraft[m has quit (*.net *.split) |
| [00:29:57] | * Cata[m]1 has quit (*.net *.split) |
| [00:29:57] | * jgaehring[m] has quit (*.net *.split) |
| [00:29:57] | * shane_aldrich[m] has quit (*.net *.split) |
| [00:29:57] | * MatrixTravelerbo has quit (*.net *.split) |
| [00:33:41] | * jgaehring[m] has joined #farmos |
| [00:37:19] | * DanielAshcraft[m has joined #farmos |
| [00:38:02] | * Cata[m]1 has joined #farmos |
| [00:38:02] | * shane_aldrich[m] has joined #farmos |
| [00:41:38] | * JulianF[m] has quit (*.net *.split) |
| [00:41:38] | * paul121[m] has quit (*.net *.split) |
| [00:41:38] | * farmtech[m] has quit (*.net *.split) |
| [00:43:10] | * MatrixTravelerbo has joined #farmos |
| [00:46:02] | * paul121[m] has joined #farmos |
| [00:46:02] | * farmtech[m] has joined #farmos |
| [00:47:49] | * JulianF[m] has joined #farmos |
| [08:24:16] | <botlfarm[m]> | thanks mstenta. I attempted to open the edit page directly "/taxonomy/term/97/edit" and get the same error. Unless there is another way to get to the edit form I don't think this will work. |
| [08:24:51] | <botlfarm[m]> | Any clue where I should be looking in the database itself for this? |
| [08:24:59] | <mstenta[m]> | ah ok - well then... to the database! :-P |
| [08:25:00] | <mstenta[m]> | yes... |
| [08:26:03] | <mstenta[m]> | in 1.x, area geometry is stored in the `field_data_field_farm_geofield` table |
| [08:26:18] | <mstenta[m]> | (as well as the `field_revision_field_farm_geofield` so we'll need to update both) |
| [08:28:07] | <mstenta[m]> | probably what we want to do is pinpoint the area that has an issue and then just delete the record from each table |
| [08:28:13] | <mstenta[m]> | this will essentially clear out the geometry for that area |
| [08:28:24] | <mstenta[m]> | then you should be able to get into the `/edit` page and redraw it |
| [08:28:45] | <mstenta[m]> | (always a good idea to take a quick database snapshot first) ;-) |
| [08:29:09] | <mstenta[m]> | `SELECT * FROM field_data_field_farm_geofield WHERE entity_type = 'taxonomy_term' AND bundle = 'farm_areas';` |
| [08:29:40] | <botlfarm[m]> | Im actually working in an entire backed up copy right now to make sure I'm doing it right before moving on to production. but will defiantly get another backup first. |
| [08:29:43] | <mstenta[m]> | that query will filter down to just areas |
| [08:30:03] | <mstenta[m]> | i think what you want is: `SELECT * FROM field_data_field_farm_geofield WHERE entity_type = 'taxonomy_term' AND bundle = 'farm_areas' AND entity_id = 97;` |
| [08:30:23] | <mstenta[m]> | that should give you the exact geom |
| [08:30:51] | <mstenta[m]> | it's stored in Well-Known Binary in the db, so you won't be able to easily read it... i think there's a way to get WKT in a query... i forget |
| [08:31:05] | <mstenta[m]> | but if you're OK with just deleting and redrawing then you don't need to read it |
| [08:31:31] | <botlfarm[m]> | perfect. Yeah im fine deleting this altogether |
| [08:31:59] | <mstenta[m]> | If you feel confident that this is the correct geometry, these two queries will delete it from both tables:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/c7ec9cf753...) |
| [08:32:06] | <botlfarm[m]> | the odd thing is there are only 9 logs that reference this geometry and they all have closed polygons |
| [08:32:26] | <mstenta[m]> | then try going to `/taxonomy/term/97/edit` again |
| [08:32:38] | <mstenta[m]> | that is odd |
| [08:32:50] | <mstenta[m]> | maybe this one was edited/corrupted after the logs were created? |
| [08:33:10] | <mstenta[m]> | (that's one of the benefits of cloning area geometry to logs! backups :-) ) |
| [08:36:44] | <botlfarm[m]> | perfect. deleting that worked. now I can get in and edit it. Thanks! |
| [08:37:18] | <botlfarm[m]> | or more importantly continue the 2.x migration |
| [08:38:40] | <mstenta[m]> | woo! |
| [08:39:01] | <mstenta[m]> | botlfarm: i am days away from releasing alpha3 FYI! |
| [08:39:31] | <mstenta[m]> | so maybe plan accordingly ;-) |
| [08:40:08] | <mstenta[m]> | still worthwhile to practice migrating right now - but plan to reinstall and re-migrate once that is released too |
| [08:40:19] | <botlfarm[m]> | Excellent. I mainly just wanted to see how the migration would work now that im in a linode server. |
| [08:40:27] | <mstenta[m]> | alpha3 will probably be the last alpha before beta1 - and *may* end up being "stable" in that regard |
| [08:40:37] | <mstenta[m]> | a lot of the major changes are done, or will be for alpha3 |
| [08:40:52] | <botlfarm[m]> | cool |
| [08:41:08] | <mstenta[m]> | oh are you using sensors? |
| [08:41:29] | <botlfarm[m]> | I do have a handful of temp sensors |
| [08:42:03] | <mstenta[m]> | if so, i might recommend waiting to test the sensor data migration until after alpha3 |
| [08:42:04] | <mstenta[m]> | paul121 refactored the migration to be MUUUUUUCH faster |
| [08:42:08] | <mstenta[m]> | (a big db with lots of data would take 8+ hours to migrate before - now it's minutes) |
| [08:42:45] | <botlfarm[m]> | good call |
| [08:43:23] | <mstenta[m]> | if you just leave the `farm_sensor` module turned off then the migration won't run |
| [08:43:47] | <mstenta[m]> | (more specifically the `farm_sensor_listener` module... you can actually leave `farm_sensor` on and migrate the `sensor` assets without the data) |
| [08:44:06] | <mstenta[m]> | (`farm_sensor_listener` will enable the data migration) |
| [08:44:51] | <mstenta[m]> | on a related note... i'm adding some documentation right now about migrating sensor data specifically to the migration docs |
| [08:45:09] | <mstenta[m]> | and how to limit "downtime" of your sensor data streaming, during migration, if that's important |
| [08:45:44] | <mstenta[m]> | in either case, be sure to follow the updated migration docs once alpha3 is released... there are a few minor differences |
| [08:46:14] | <mstenta[m]> | notably, we are adding a single `farm_migrate:import` drush command, which will run all the migration groups for you, so you don't have to do them individually |
| [08:46:19] | <botlfarm[m]> | I honestly just added sensors to farmos for the fun of it. I never actually look at them. Looking now it looks like they stopped updating about a month ago. oops. I will probably just start fresh in 2.x |
| [08:46:41] | <mstenta[m]> | ah well that makes things simpler haha :-) |
| [10:18:11] | <symbioquine[m]> | <mstenta[m]> "paul121 refactored the migration..." <- Is that just for the sensors part of the migration? |
| [10:18:24] | <mstenta[m]> | yes |
| [10:19:15] | <mstenta[m]> | oh but that reminds me symbioquine i know you had some automated migration testing code... you will need to make a few small changes for alpha3 |
| [10:20:24] | <symbioquine[m]> | I=[👂️👂️] |
| [10:21:06] | <symbioquine[m]> | I plan to retest that migration/automation soon... |
| [10:21:20] | <mstenta[m]> | well for one... maybe you can just simplify completely... we added a `drush farm_migrate:import` command |
| [10:21:28] | <mstenta[m]> | this automatically runs all migration groups in the correct order |
| [10:21:34] | <mstenta[m]> | also there is `drush farm_migrate:rollback` |
| [10:21:38] | <symbioquine[m]> | ah, nice! |
| [10:22:03] | <mstenta[m]> | you *may* need to increase the `memory_limit` of Drush... i am documenting how to do that in the migration docs right now |
| [10:22:23] | <mstenta[m]> | i only ran into an issue with sensor data though, so maybe you won't need to - but it's kinda nice to give php cli a bit more memory anyway |
| [10:22:50] | <mstenta[m]> | other than that, i renamed `farm_migrate_reference` group to `farm_migrate_asset_parent` |
| [10:22:59] | <mstenta[m]> | and resolved the rollback issues |
| [10:24:12] | <mstenta[m]> | there are two other migration changes happening before alpha3 (almost merged): material type terms + quantities, and data stream migration improvement |
| [10:28:47] | <mstenta[m]> | > other than that, i renamed `farm_migrate_reference` group to `farm_migrate_asset_parent` |
| [10:28:47] | <mstenta[m]> | (i also changed WHEN this group runs... after asset/area migrations, instead of the very end, but it doesn't really matter) |