<div dir="ltr"><div>Hi Paul:</div><div><br></div><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Fri, Feb 14, 2025 at 3:32 AM Paul via pycsw-devel <<a href="mailto:pycsw-devel@lists.osgeo.org">pycsw-devel@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div style="font-family:Helvetica Neue,Helvetica,Arial,sans-serif;font-size:13px"><div dir="ltr"> <div><span style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">Hi team, yesterday i had a short meeting with Massimo di Stefano, related to their work on pycsw+solr. </span><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">A nice work available at <a id="m_140117879731547089ydp63d86019menurh9" href="https://github.com/epifanio/adc-pycsw" title="https://github.com/epifanio/adc-pycsw" rel="nofollow" target="_blank">https://github.com/epifanio/adc-pycsw</a>. At ISRIC we’re interested to contribute </div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">to the further development of that work. But would like to understand some aspects of it.</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><br></div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">At the moment pycsw is heavily bound to a relational database, I understand this aspect has been introduced with the flask app.</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">I understand there are ambitions to refactor this aspect so the database becomes optional. </div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><br></div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">How concrete are the plans for such a refactor, should we set up a branch where contributions can be added or organise a code sprint? Is there an RFC with some design ideas?</div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><br></div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">On timeline, I assume the release v3 has now most priority, so major developments are not desirable. </div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px"><br></div><div style="color:rgb(0,0,0);font-family:Helvetica;font-size:12px">Thank you for your thoughts...</div></div><br></div></div></div></blockquote><div><br></div><div>Yes, this has been discussed with Massimo and others in terms of abstracting the RDBMS dependence.  Currently, one can bind pycsw to a non-RDBMS backend, but it will lack transactional capability.  The other current limitation is that the Docker entrypoint is tied to a repository startup and there are bits of RDBMS-isms in those codepaths.</div><div><br></div><div>I'm planning an initial implementation of a "next gen" repository functionality in April/May 2025 and will ask for help/contributions at that time, once there is a scaffold (which will heavily depend on pygeofilter).  Whether it actually replaces the current repository concept (as opposed to being another option) is still TBD.  The main goal would be to achieve parity with current unit and functional testing.  I will reach out here and GitHub in April on next steps, but the main plan would be to have something in master branch hopefully by end of summer 2025.</div><div><br></div><div>Thanks</div><div><br></div><div>..Tom</div></div></div>