Part-DB 1.0 Milestone development discussion / Roadmap

[jbtronics]

The purpose of this issue is to allow discussions about the development of Part-DB 1.0 and create a roadmap for further development:

I have added kanban boards (https://github.com/Part-DB/Part-DB-symfony/projects) for all features I would want to see in (near) future Part-DB versions. Not everything must be in the Part-DB 1.0 milestone, but can be implemented in later versions too.

I think for the Part-DB 1.0 release it would be useful to implement all features of the old Part-DB versions (Part-DB 0.5/0.6), to allow existing users to migrate to the new version and to profit by the new "comfort features" quickly. Also this has the advantage that we don't have to maintain two completely different versions at the same time for long.

To achieve this I would recommend that the development of Part-DB 1.0 concentrates on implementing the features missing in comparison to the old versions. That does not mean that new features are completely forbidden, in many cases it is very reasonable to implement new features, especially when they are related to the architecture or would be difficult to add in a later stage of development (like logging system):

For example the project management and order system in the old versions is very odd and not really useful for real life applications. For Part-DB 1.0 these features should be implemented in a meaningful way (with a new architecture), which automatically will add new features. If these deep changes the architecture would be introduced in later versions, it would be more work to implement the new features than doing it now all at once.

Besides the development of the codebase there are also some other things that has to be done for a good Part-DB 1.0 milestone: Documentation/Help (especially on the usage) and maybe some additional translations.

If you have ideas, critique or recommendations about this topic, feel free to discuss it in this issue,

[jbtronics]

My plans for the (bigger) things I want to implement in the next time would be these (ordered by descending priority):

• [x] Log system
• [x] Part parameters
• [x] Project system
• [x] Barcode generator and scanner
• [x] Filter system for parts

[coeka]

I'd love to see an update system. I am running part-db on a Rpi and i am not that familiar with Linux. I'am looking forward to use the new version, but i am also afraid of updating it.

[chrisnoisel]

Seems reasonable to aim at the feature level of 0.5.6. However, I would have though that the import feature would appear higher on the priority list. I don't think we can mass import parts in 1.0 yet, while it won't bother those with pre-existing databases, that makes the tool hard to use for new comers (they have to import in 0.5.6 first, then upgrade to 1.0.0, I guess)

In the "far" future, I'd like to work on custom views for categories. For example a category about MOSFET can show columns like Vgs, Ids, package, etc. If that's an interesting thing to plan we should as soon as possible decide how we should store the part information in the current database (maybe in the description field, in csv format, it's human readable and we can easily parse it) so we don't have to rebuild all our databases later. Actually, having the ability to filter and sort with these information (like radiospare/mouser/digikey...) would be a great deal. I would probably require some kind of search library that can produce facets etc.

[jbtronics]

Okay, i agree that a Part-DB 1.0 release should have an part import system. A basic one (like the current import system for categories etc.) should be easy to implement (the most of the hard work like parsing the different file formats and putting the data into model objects, is done by Symfony Serializer component).

For the part properties: my plan was to use the JSON datatypes of the newer MySQL versions, which allows to save arbitrary data sets in a single column. The data inside the JSON types can be SELECTED and used in WHERE clauses similar to real columns, so the implementation of the part properties and filter them later should be rather easy (from database point of view). See https://www.mysqltutorial.org/mysql-json/ for some examples The only downside on this approach is, that at least MySQL 5.7 (or MariaDB 10.2) is required (PostgreSQL would have that type too). For all older database we could use the doctrine fallback (using a simple TEXT field and do Json serialization in PHP). In that cases you can edit and view part properties just like the other DBs but you would not be able to filter by properties (which should be manageable)

[chrisnoisel]

That's a more elegant approach to what I could have come up to, I've drop web development years ago anyway :) I've never used it so I can't say anything about potential performance issue on complex requests but we're probably good.

[jbtronics]

The performance of this JSON columns is a good point. I know that some other inventory software (EleLa, page is in german) uses JSON for the part properties and it seems to work without problem.

Also I dont think Part-DB will not be used manage millions of Parts each with hundreds of properties. Also property filters will most likely be applied to parts in a specific category (e.g. all diodes with a specific forward current), so the DB has to filter just a few parts. (Also the fields like comments can not be indexed too, because they are too long. For really big inventories you would have to use a companion search database (like elasticsearch) to improve performance).

Anyway I will do some some performance test before implementing the part properties.

[AlexanderS]

Is there a list of missing features? The only issues in the 1.0 milestone is this issue and #5.

[jbtronics]

@AlexanderS I have updated the list above. Everything which does not have a tick is missing yet, and needed for 1.0 milestone (as this are features existing in 0.5).

In the current versions basic part instock managment should work. It is not really polished yet and some workflows are not perfect yet (for example to remove a part from instock or move it, you still have to go to part editor). Currently I am working on part (and other entities) parameters (which ultimately should allow for parametric searches), afterwards I will propably work on project system.

[Murmele]

@jbtronics With "Filter system for parts" you mean something i described in #77 ? Sorry than for creating the issue

[Peter-Krebs]

@jbtronics Using the old version of Part-DB and eager to try the new one, thanks for making this!

Is there an update on the currently implemented features?
Thanks!

[jbtronics]

Filter system for parts and parametric search is now working (besides some smaller quality of life improvements). See announcement #174

[Murmele]

@jbtronics Thank you for your efforts!