Getting started from scratch? Ain't nobody got time for that!

[TinkerTob]

Hello everybody,

I've recently set up Part-DB (had no inventory system for electronics parts whatsoever before) and I generally love it.

However, the prospect of populating it (and doing it right, including footprints and stuff) from scratch seems pretty daunting... Let's just take resistors, for example. If I fill out the "new parts" form for every type of resistor I have, it will take ages. Even if I clone the same resistor over and over again.

Now, I'm thinking about creating a single resistor, exporting it to csv, adding the other types in the csv and reimporting it... but that seems kinda ugly to me. Besides, resistors are only one example.

Let's talk units of measurement, for another example. I've been constantly stumbling over ones that I haven't yet defined. Now, I'm all for customization, but I'm pretty sure that we're all using mostly the same units... Call me lazy, but to me it seems unneccessary that I (and everey other new user) have to re-define those myself. But I didn't find an alternative, neither in the docs nor using Google.

My first instinct was something like "there must be some kind of online database, where Part-DB users can directly share these things with each other". Buuuut I didn't find anything of that sort. Besides, if there was, I'd have expected is to be listed as an information provider.

Soooo: Am I just too blind and did I overlook something obvious? Or is there really currently no way to speed up that initial database population?

I'm grateful for any hints and tips. Besides, I think such an "online database" for Part-DB resource sharing would be really cool. Or at least some defaults for really basic parts, units, whatever, that new users could download (maybe from the Getting Started docs) and import.

Thank you all!

[virtadpt]

You don't have to enter each and every one into a separate part. There are lots of different ways of going about it: If the exact number of parts isn't important to you, you don't have to enter them (for a lot of stuff, I don't, I care about the storage location on the Stocks tab way more). You can put it into the notes for that part (e.g., "I have between 15 and 30 110 ohm resistors.") If they're part of a collection you can enter the entire collection as a single part ("Prototyping perfboard kit") with the specifics in the notes ("2x8 cm x3; 3x7 cm x5, 7x9 cm x3") or as fields on the Parameters tab for the kit.

Don't think of Part-DB-server as an inventory, think of it as a tool to build an inventory specific to your use case and how you think.

[TinkerTob]

I'm not exactly sure about what you're trying to tell me with that last statement... First sentence of the readme: "Part-DB is an Open-Source inventory management system for your electronic components." That's exactly what I'm trying to do: Im trying to build and manage an inventory.

What you're suggesting might work, but I'd lose all the advantages of using such a system. I couldn't decrease stocks at the click of a button. I couldn't add a specific item to a BOM. I couldn't look the available items up from KiCAD. In fact, I could just use an Excel spreadsheet.

However, you are giving me an idea on how that could be solved very nicely: "Sub-Parts" that inherit from each other.

Possible workflow:

1. Create a parent part (e.g. a "1W 1% Metal Film Resistor") with all fields filled out
2. Go to a (new) "children" tab on that part
3. Select in which fields the "children" differ from the parent part
4. Fill out a table: one row for each "child", one column for each of the selected fields
5. Create all these parts at once with the supplied values. For any other value, refer to the parent part.

As an additional bonus, this could be implemented in such a way that all sub-parts share the same attachments etc. and that updating the parent part would automatically update all the children. This would be great for associated parts: Let's say I later add "carbon film resistors" to the inventory. I could just associate this parent part with the "metal film resistor" parent part, and this could automatically propagate to all the sub-parts that share the same resistance. (The latter could be solved by either just using the first parameter, or by allowing parameters to be marked as mandatory... but I'm losing myself in details of implementation here.)

The cherry on top would be if it was possible to use parameters as variables in the part name, thereby automatically turning a [[Resistance]] Resistor into a 1 Ohm Resistor.

Is there something like this already? Or would this be worth a feature request?

[jbtronics]

Let's talk units of measurement, for another example. I've been constantly stumbling over ones that I haven't yet defined. Now, I'm all for customization, but I'm pretty sure that we're all using mostly the same units... Call me lazy, but to me it seems unneccessary that I (and everey other new user) have to re-define those myself. But I didn't find an alternative, neither in the docs nor using Google.

My first instinct was something like "there must be some kind of online database, where Part-DB users can directly share these things with each other". Buuuut I didn't find anything of that sort. Besides, if there was, I'd have expected is to be listed as an information provider.

Currently there are no such presets for datastructures. I am planning this for a while already, but I had never the time to implement it. And it properly is not so easy to define presets which are useful for everybody. I guess for footprints and manufacturers thats pretty easy as there are just a few common ones around. But for suppliers everything is pretty regional dependent, and for categories everybody has most likeley a different taste. Then you have maybe different languages, and so on. Making this everything not so trivial, if it should be universal and expandable.

However in my opion it already speeds up a lot if you import the parts from an information provider, like octopart, digikey, mouser and so on.
If you have no matching datastructures already, it will use the information from the info provider and by clicking save, all not yet existing datastructures get created instantanous. For categories you can copy and paste the suggestion provided by the info provider.

In that way you can pretty easily replicate the organisational structures from the information providers, without manually creating them. Just by importing parts with 3 clicks.

Sure they still miss metainformation (like contact informations for the manufacturers), but these are not so important normally and you can easily add that afterwards if you want.

[TinkerTob]

Hi @jbtronics! Thank you for taking the time to answer, and most of all: Thank you for all the time you put into this project.

Currently there are no such presets for datastructures. I am planning this for a while already, but I had never the time to implement it.

I think we might have misunderstanding here - and maybe even a fundamental difference in opinion.
Personally, I think that presets (aside from really obvious ones) are not an optimal solution. You stated the reasons yourself: Differences in taste, regional differences, different requiremeents, and so on. Besides, such official presets take a lot of work to create and maintain, which would probably bite you in the ass sooner or later. Probably sooner, because once you start implementing them, people will start demanding more.

What I was talking about are two completely different concepts:

1. A way of sharing data in the community.

Part-DB already has nice import and export capabilities... All that's needed is a place were users can share that data. In theory, that could be an independent, unofficial online forum. However, an official (user-curated) database-like solution that could be used by Part-DB as an information provider and to which users could contribute parts directly from their Part-DB instance would be much better.

Once such a "marketplace" got going, how it gets used would be totally up to the community. Datastructures could be shared, and new users could decide wether to use an existing one or wether to create their own. Parts could be shared, saving users the trouble to fill out fields that other data providers are lacking (such as KiCAD footprints). But noone would be forced to use it, and noone could expect you to maintain any of the data. Missing something? Submit it yourself. Found something outdated / false / offensive? Volunteer as a mod and correct it yourself. It would be totally up to the community.

This could even be used as a way to share plugins, in case you ever intend to implement something like a plugin system. For example, I could easily imagine sharing scripts for scraping local electronics suppliers like reichelt and conrad.

2. A faster way for bulk-creation (and modification) of parts

However in my opion it already speeds up a lot if you import the parts from an information provider, like octopart, digikey, mouser and so on.

That's true, for individual parts.
However, it becomes messy when trying to enter variations of a part. Resistors, capacitors, you name it - there's several scenarios where dozens of individual parts share almost all of their attributes, but should (in my opinion) still be treated as individual parts. Entering those one by one is pretty cumbersome, even if you go the (imo counter-intuitive) route of grouping them in a subcategory and assigning the attachments to the category instead of the individual parts.

---

On a personal note: Please don't take this the wrong way. I've made the experience that such extensive suggestions by outsiders are often seen as demands, meddling, or even as an attack. That's not at all my intention. I respect that this project is your brainchild, on which you've done a really great job and will no doubt continue to do so. And I'm aware that what I'm suggesting might be entirely based on misconceptions and noobish behaviour on my part. However, even if that's the case, I think that the misconceptions and rash opinions of a novice user can be valuable feedback, since they're coming from an outside perspective that's mostly barred to the developers or experienced users of a project. That's why I tend to state them at length, and that's also why I made this a discussion instead of feature requests.