| [08:00:33] | <jgaehring[m]> | hi jubha mayala , just realized your post got flagged as spam, but I just unblocked it. our spam filters a bit too eager, I'm sorry to say, working to try to make them better, but in any event, welcome to the farmOS community! 👋 |
| [11:30:36] | <paul121[m]> | farmOS dev call in 30 min! |
| [11:31:24] | <mstenta[m]> | Thanks for the reminder! I forgot! 😅 |
| [13:10:34] | * MarcosCarballal[ has joined #farmos |
| [14:26:07] | <MarcosCarballal[> | Hi everyone, I just wanted to make you all aware that I have submitted a bug report here. https://github.com/farmOS/farmOS/issues/451. |
| [14:27:40] | <mstenta[m]> | Thanks Marcos Carballal ! I'll take a look - appreciate the bug report! |
| [14:32:03] | <MarcosCarballal[> | No problem. It is not impacting my current workflow (it still creates the field), but probably worth investigationg |
| [14:32:59] | <mstenta[m]> | Cool cool - I commented on the issue - will look a little closer to fix it :-) |
| [14:33:06] | <mstenta[m]> | How's everything going with your development stuff? |
| [14:38:18] | <MarcosCarballal[> | It's going well! We have a Proof of Concept data flow from FarmOS to the CIG database. |
| [14:38:31] | <mstenta[m]> | Very cool! |
| [14:40:41] | <MarcosCarballal[> | I'm currently going through the laborious task of adding all the fields and pulling out the types from Configuration Manager. But once that is done we can actually start focusing on building a more feature-rich relationship between the CIG database and farmOS. |
| [14:41:03] | <mstenta[m]> | Great! |
| [14:41:34] | <mstenta[m]> | One tip (maybe you know this already): you can do a bulk export of ALL config entities into a zip file... if you're spending a lot of time doing single exports that might be faster |
| [14:42:44] | <MarcosCarballal[> | Yup, that's what I'm doing. I just have 50+ tables to convert to Taxonomies |
| [14:43:12] | <mstenta[m]> | gotcha haha yea that's a lot |
| [16:27:05] | <MarcosCarballal[> | I want to verify that there is no notion of "parameterized fields". I.e. Can I reuse the same field through the UI, but pass in an argument to the field. Right now, I am hoping to be able to change the maximum char length of field depending on which Taxonomy is using it. |
| [16:32:14] | <mstenta[m]> | Ah yes some things can be configured on a "per bundle" basis, but other things are shared across all bundles (taxonomies) |
| [16:32:45] | <mstenta[m]> | Max character length might be shared across |
| [16:33:02] | <mstenta[m]> | Because I'm assuming it is used directly in the database table schema that's created |
| [16:33:26] | <mstenta[m]> | However... You might be able to achieve what you want by limiting the max characters in the form input side |
| [16:36:57] | <MarcosCarballal[> | Well in this case of taxonomies we are strictly importing this data from the national reference tables (NRT). So maybe I just find the largest value present for maximum char length and set it equal to that (Something like 4000 chars). I assume that Drupal is capable of handling a datatype like that. |
| [16:37:31] | <mstenta[m]> | Yea that should work |
| [16:38:17] | <MarcosCarballal[> | Okay, I will do that then. Not worth defining a new field for rows that have the same semantic meaning, only differing the number of max chars allowed |
| [16:39:16] | <mstenta[m]> | Yea if this is just syncing reference data that should work fine |
| [16:39:28] | <MarcosCarballal[> | Great, thanks for the insight |
| [16:39:35] | <mstenta[m]> | If new data is being created in farmOS then you can validate on input too |
| [16:40:39] | <MarcosCarballal[> | Yes we could, but I don't think we are going to have that many similar column types for data that is being input. So hopefully it works out to be easy. |