New WP algorithm

[wonder-sk]

No description provided.

[PeterPetrik]

very nice, reading done, let me do some testing now!

[PeterPetrik]

additional questions

1. you can split by 1 gpkg at the moment , right?
2. config.db must be prepared manually by user?
3. does we support filtering. so in the master we have teams A, B, C, but we do not want to create workpackages for team C

[PeterPetrik]

I prefer to use the same as in mergin-py-client

let the user setup MERGIN_URL and MERGIN_AUTH tokens generated by mergin login.?

[wonder-sk]

Hmm the problem with MERGIN_AUTH token is that it is short-lived, only working for a few hours, then requiring a new login...

[PeterPetrik]

ok ... support both in that case?

[PeterPetrik]

to be able to run it with my example I had to remove spaces from the team names

Downloading master project peter.petrik/workpackageinitial...
Done.
Reading configuration from /var/folders/9_/1ntz1sgx1qgflk2pyshntrmr0000gn/T/mergin-work-packages/master/work-packages/config.db
Master project files to copy to new projects: ['testproject.qgz']
First time encountered WP Team B - not collecting input
First time encountered WP Team A - not collecting input
existing WPs: []
delete from mydata where team != 'B'
remap.mydata_Team B

        CREATE TABLE IF NOT EXISTS remap.mydata_Team B (
            master_fid INTEGER PRIMARY KEY, wp_fid INTEGER UNIQUE);
    
Traceback (most recent call last):
  File "wp_mergin.py", line 126, in <module>
    make_work_packages(wp_alg_dir, wp_names, wp_tables)
  File "/Users/peter/Projects/mergin/mergin-work-packages/wp.py", line 261, in make_work_packages
    remap_table_master_to_wp(c, table_name, wp_name)
  File "/Users/peter/Projects/mergin/mergin-work-packages/remapping.py", line 60, in remap_table_master_to_wp
    _create_remap_table_if_not_exists(cursor, remap_table)
  File "/Users/peter/Projects/mergin/mergin-work-packages/remapping.py", line 29, in _create_remap_table_if_not_exists
    cursor.execute(create_sql)
sqlite3.OperationalError: near "B": syntax error

by

def remap_table_name(table_name, wp_name):
    """ Returns name of the mapping table used for a particular table name and work package """
    table_name=table_name.replace(' ', '_')
    wp_name=wp_name.replace(' ', '_')
    remap_name=f"remap.{table_name}_{wp_name}"
    print(remap_name)
    return remap_name

[PeterPetrik]

I suggest to use different naming to the resulting projects, where the original project name would be part of the work_packages names. ...

imagine you create 100 workpackage projects and how the dashboard will look like. if we use some consistency, in the future we can group the subprojects in the collapsible menu in the mergin web? (i think it will be pretty much must-have from first release)

[PeterPetrik]

Also I think we should braninstorm the configuration files in general. I think that

1. configuration file (config.db) should be probably in the mail folder or the configuration subfolder (?) (not in the work-packages subfolder) and we should have some naming consistency for all configs (imagine in the future configs for web-maps, integratrions etc)
2. work-packages subfolders should be probably hidden (sub-dir with dot (.) at the beginnning?)

[PeterPetrik]

it looks like this is not working
A) create work-packages
B) delete a feature from the main project
C) run the wp script
D) the feature is still present in the work-package

[wonder-sk]

additional questions

1. you can split by 1 gpkg at the moment , right?

Yes

2. config.db must be prepared manually by user?

There's config.sql to create structure, then in can be populated e.g. in QGIS.

3. does we support filtering. so in the master we have teams A, B, C, but we do not want to create workpackages for team C

Yes - simply we would not add an entry in wp_names for team C. It is also possible to have data shared by two teams at once (but not tested properly yet).

[wonder-sk]

to be able to run it with my example I had to remove spaces from the team names [...]

Added #9

[wonder-sk]

I suggest to use different naming to the resulting projects, where the original project name would be part of the work_packages names. ...

I don't have a strong opinion... the way how it is now was just the easiest to implement 🙂

Also I think we should braninstorm the configuration files in general [...]

Yeah we should probably move it to top-level directory and rename it. As for internal files... we could use a hidden dot directory, but on Windows it would still show up I guess?

it looks like this is not working
A) create work-packages
B) delete a feature from the main project
C) run the wp script
D) the feature is still present in the work-package

As discussed already, it should be working, probably a forgotten push...

[PeterPetrik]

nice nice... happy to close this one...