If we want to add 100+ fields to a asset would it be better to add the fields to the base asset or create a expansion module and putting all custom fields in the own table and liking those tables back to the asset?
1 Like
@WHFarms wow that’s a lot of fields! May I ask what types of data you’re trying to capture?
Ideally you would leverage Drupal’s Entity and Field APIs, so all you would need to do is create a custom module with some PHP code that declares the basic information about the fields you want, and you would let Drupal take care of the rest. It will create the necessary database tables for you, and link everything together within it’s internal ORM so that you get all the benefits of the APIs automatically, including making the data accessible via the JSON API endpoints.
We have some farmOS-specific documentation for adding fields here:
But I would definitely recommend thinking hard about your data model before you start creating tons of fields. IMO assets should have as few fields as possible on them, and record keeping data should be captured in logs that reference the assets instead. That is based on the assumption that the data you want to collect is time/event-based though. Asset fields are best used for attributes that are “intrinsic” to the asset and will never change. This is why, for example, assets do not have a “location” field on them… that is captured by logs instead because it changes from time to time.
If you’d like help thinking through the best way to model the data you’re trying to collect, feel free to post a list of the fields you are thinking about and we can help think it through.
1 Like
For what it’s worth, there has been some recent discussion around adding a new way to record asset attribute information via logs that might help here:
1 Like
I read this the other day. Brilliant.
Here is a start. So much more thought but I think a person can overthink it and never get off home plate.
I also am thinking about Tags. They are not really logs but tags. Many to Many Tags to Assets. You could group cattle by pen, sex, Breed/Open, Future Breeding Stock, Commercial, Registered, Farm1 or Farm2, Feeders, Finishers. If these all could be tags then using a couple joins reporting by Tag is fairly straight forward.
@WHFarms thanks for sharing that! It would help to have a short description of each to make sure I’m understanding them correctly, but at quick glance it does seem like a lot of them would benefit from being modeled using the “asset attribute operations” ideas discussed in Generalizing Log-based Asset Attributes
That said, there’s no timeline on that work at this point, so it won’t help in the short term. I would hesitate to recommend adding a bunch of custom fields though, unless you are also planning an upgrade path to migrate the data to the core model in the future.
The nice thing about farmOS is it’s flexibility: you can add whatever fields you want! The bad thing about that flexibility is: you are responsible to maintain any custom stuff you build. So sticking closer to the core model has the benefit of outsourcing that maintenance to the larger community. Of course, there are tradeoffs either way. Community-maintained code is slow to change, and that’s a good thing because it has more momentum and stakeholders who depend on it. Custom code can be nimble, “move fast and break things”, serve your individual needs, etc… but it’s all your responsibility.
A simple first step that might be worth considering is making a custom module that adds some Animal-specific “Flags”, which you can use to tag each animal asset. farmOS core only provides three flags out of the box (“Priority”, “Monitor”, and “Needs Review”) which can be applied to any asset or log type. But it’s also possible to provide your own types, and limit which asset/log types they can be applied to.
I’ve seen this used to create a flag called “Bummer” on a lambing operation, for example.
Flags are nice because they are easily visible/filterable from the main asset lists out-of-the-box. But adding/removing them is not tracked via logs, so you won’t be able to easily track when an asset was flagged, or when flags changed on it. If you need that kind of history then logs are the recommended way to record that. And if/when we have the “asset attribute operations” feature built, there will be a lot more flexibility to log changes against specific asset attributes. I think that will be a very nice addition to the core data model.
Hope that all makes sense and helps you think about options!
2 Likes
After reading though some additional changes being made to logs and seeing how those changes being important to the success of the large animal module I am going to hold on my investment into this.
I have a the basics figured out enough that I could secure a small group of programmers to build this module, but see the changes coming to logs as having lasting effects that should be considered in the preliminary design.
1 Like