odcb connector development and usage

[Rico Schmitt]

Hi there,

TLDR: Is the odbc connector here to stay? Are there any development
plans for it? I tried it and found some issues using it, I have
implemented a draft of my ideas. See PR:
https://gitlab.com/kicad/code/kicad/-/merge_requests/1654

We would like to have another go and move more projects from Altium to
Kicad. As there will be a transition period where both Altium and Kicad
will be used, I need to be compatible in terms of the database
connection.  I don't know if this is a common setup for Altium users or
if it's just us, but we have a single database table (actually a view)
with a column for part 'Category' such as R,C,L. I wanted to use the
same table for both Altium and Kicad, but I had two problems with the
new odbc connector design:

1) I would have to create a separate database view for each part
category as there is no filter for a library configuration. Or all parts
would be in the same library.

2) Even if each library uses the same property fields, each category
needs a separate entry in the library configuration file.

I figured we might not be the only ones with such a database structure.
Or maybe others need similar features. For this reason, I have
implemented a draft and I would like to get your feedback on whether or
not this is something that you see a need for.

1) In the .kicad_dbl config file I have added a new field
"table_filter". If present, this will filter entries from the database
based on <columnname=value>. This is a simple filter. With this there is
no need to create separate Views for each category. This should do the
job for simpler setups.

2) I added another field to the .kicad_dbl config file, since all parts
are in the same table anyway and share most or all of their properties.
It is called "libraries_template". It has the same structure as the
existing libraries field, but does not create a library entry directly.
Instead, it queries the table once on refresh and finds the filter
column's unique values. A new library entry based on the
libraries_template is created for each unique value in the filter
column. The value of the filter is used as the name of the new library.

With these two changes, it is possible to specify the library properties
once. Together with a filter column, as many entries as needed are then
generated. If a new category is added to the database, there is no need
to create and distribute new database views and config entries to all
devs. The same config file can be used and new library entries will be
generated automatically.

See PR: https://gitlab.com/kicad/code/kicad/-/merge_requests/1654

Happy for your feedback

[Jon Evans]

Hi Rico,

On Thu, Jul 13, 2023 at 11:19 AM Rico Schmitt <r...@ricoschmitt.de> wrote:

Hi there,

TLDR: Is the odbc connector here to stay?

Of course

 

Are there any development
plans for it?

Yes, can you be more specific?

 

I tried it and found some issues using it, I have
implemented a draft of my ideas. See PR:
https://gitlab.com/kicad/code/kicad/-/merge_requests/1654

I will review your MR when I have some more time and give feedback.

Note that we generally ask that people discuss their ideas by email or in an issue _before_ writing code.

It is best to get on the same page with the lead development team up front, so that you aren't in the situation of having lots of code written that will not be merged.

I haven't reviewed your code yet so I cannot say one way or the other about your MR.

 

-Jon

[Rico Schmitt]

Hi Jon,

Thanks for your reply. Happy to hear it will stay!

Note that we generally ask that people discuss their ideas by email or in an issue _before_ writing code.

It is best to get on the same page with the lead development team up front, so that you aren't in the situation of having lots of code written that will not be merged.

I haven't reviewed your code yet so I cannot say one way or the other about your MR.

No worries. I understand. My goal was not to get exactly this merged but more to show (in code) what I meant is needed. Also I wanted to experiment with the workflow and see what works and what not, what is actually needed. Therefore I needed a implementation to play around.

Are there any development
plans for it?

Yes, can you be more specific?

I don't want to introduce a part management workflow which is not in line with future kicad releases. This would force me to change it again or do custom builds. Both I would like rather not to do :). I don't have anything special in mind, but I could not find to much about future plans for the odbc connection itself and it felt like there is probably more to come.

Rico

PS: Sorry Jon if you read that twice now. I just realized my earlier reply was to you only instead of the list.

--
You received this message because you are subscribed to the Google Groups "KiCad Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to devlist+u...@kicad.org.
To view this discussion on the web visit https://groups.google.com/a/kicad.org/d/msgid/devlist/CA%2BqGbCABnnvuF%2BYdVji40wEaKLgDKS5a8j8%3DG95xQNkAnJuQXQ%40mail.gmail.com.