Re: [SOGo] SOGo database schema
Cédric Archambeau quatschte am Wed, Dec 29, 2021 at 12:22:34PM +0100: > Hi Andre, > > Lots of disagrees with the form in your message. > > Remember you benefit from a FOSS. > Not OK with some feature ? Report a bug, maybe pull a request (*you* could > hire a database administrator to redesign database schema), or discuss (not > assault !) it here. > > SOGo nightly is *free*, but *not a due*. > > Sorry if i feed the trolls, but you may have in mind that some of us > (community users) want to keep this list as sane as possible, and keep SOGo > devs and users away from agressive contents. > > EOT for me. Hi Cédric, completely agree with you. This was such a rude post. F/LOSS is open to everyone to contribute, so do it instead of harassing developers for doing a great job. Regards and keep up the great work SOGo Team ! Peter -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] SOGo database schema
Hi Andre, Lots of disagrees with the form in your message. Remember you benefit from a FOSS. Not OK with some feature ? Report a bug, maybe pull a request (*you* could hire a database administrator to redesign database schema), or discuss (not assault !) it here. SOGo nightly is *free*, but *not a due*. Sorry if i feed the trolls, but you may have in mind that some of us (community users) want to keep this list as sane as possible, and keep SOGo devs and users away from agressive contents. EOT for me. Regards, Cédric Archambeau Secrétariat National Solidaires Finances Publiques Pôle Communication - Informatique Le 23/12/2021 à 10:33, André Rodier (an...@rodier.me) a écrit : Good morning, all. OK, SOGo is the only working CalDAV / CardDAV server with an acceptable level of quality, at least to me, in the standard Debian repository. The two absolute requirements for me are LDAP authentication and a working user interface over https. So I have to use it, fair enough. By the way, if right now, when reading this, your mind comes up with nice repositories on GitHub or somewhere else, where I can download xxx or yyy, just stop and read again. I want to stick to a standard Debian compatible repository, this is not negotiable. Unfortunately, every time I have a look into the database schema, it is a shame, and I don't see any improvements over the years. First, the tables prefixes - seriously, what is the point of this, remove it. The tables should not be named sogo_xxx ? We are not any more in the 80s, when you were only able to use one database on a hosting provider. At least, make this an option, and not the default case. Second, the column prefixes - Why all the columns are called c_xxx, there is no point behind this except it is annoying and reduce queries readability. Do you have a dinosaur programmer in your team that advertise this as a poor way to avoid errors ? For these two "features", trust unit test, static code analysis and continuous integration to detect errors, not programming practices from the 70s. Third, why the table sogo_folder_info replicates the credentials of the database in each record ? (columns c_location, c_quick_location, c_acl_location) Even if you wanted to have multiple database, the credentials should not be stored in clear text in the database. This is both a security issue and the worst database design I have seen so far...just remove this feature. Fourth, in the same table, what are the columns c_path1, c_path2, c_path3 ??? If your database was properly designed, you wouldn't need these artefacts. For 2022, can you hire a database administrator to redesign your database schema ? Otherwise, I wish the whole team a happy new year. Andre Rodier. -- users@sogo.nu https://inverse.ca/sogo/lists
Re: [SOGo] SOGo database schema
Hi, Only to say: YES, specially on #3: the credentials in clear text inside the database. It's terrible. And additionally makes it so much more difficult to change the database credentials than it really should be. MJ Op 23-12-2021 om 10:33 schreef André Rodier (an...@rodier.me): Good morning, all. OK, SOGo is the only working CalDAV / CardDAV server with an acceptable level of quality, at least to me, in the standard Debian repository. The two absolute requirements for me are LDAP authentication and a working user interface over https. So I have to use it, fair enough. By the way, if right now, when reading this, your mind comes up with nice repositories on GitHub or somewhere else, where I can download xxx or yyy, just stop and read again. I want to stick to a standard Debian compatible repository, this is not negotiable. Unfortunately, every time I have a look into the database schema, it is a shame, and I don't see any improvements over the years. First, the tables prefixes - seriously, what is the point of this, remove it. The tables should not be named sogo_xxx ? We are not any more in the 80s, when you were only able to use one database on a hosting provider. At least, make this an option, and not the default case. Second, the column prefixes - Why all the columns are called c_xxx, there is no point behind this except it is annoying and reduce queries readability. Do you have a dinosaur programmer in your team that advertise this as a poor way to avoid errors ? For these two "features", trust unit test, static code analysis and continuous integration to detect errors, not programming practices from the 70s. Third, why the table sogo_folder_info replicates the credentials of the database in each record ? (columns c_location, c_quick_location, c_acl_location) Even if you wanted to have multiple database, the credentials should not be stored in clear text in the database. This is both a security issue and the worst database design I have seen so far...just remove this feature. Fourth, in the same table, what are the columns c_path1, c_path2, c_path3 ??? If your database was properly designed, you wouldn't need these artefacts. For 2022, can you hire a database administrator to redesign your database schema ? Otherwise, I wish the whole team a happy new year. Andre Rodier. -- users@sogo.nu https://inverse.ca/sogo/lists
[SOGo] SOGo database schema
Good morning, all. OK, SOGo is the only working CalDAV / CardDAV server with an acceptable level of quality, at least to me, in the standard Debian repository. The two absolute requirements for me are LDAP authentication and a working user interface over https. So I have to use it, fair enough. By the way, if right now, when reading this, your mind comes up with nice repositories on GitHub or somewhere else, where I can download xxx or yyy, just stop and read again. I want to stick to a standard Debian compatible repository, this is not negotiable. Unfortunately, every time I have a look into the database schema, it is a shame, and I don't see any improvements over the years. First, the tables prefixes - seriously, what is the point of this, remove it. The tables should not be named sogo_xxx ? We are not any more in the 80s, when you were only able to use one database on a hosting provider. At least, make this an option, and not the default case. Second, the column prefixes - Why all the columns are called c_xxx, there is no point behind this except it is annoying and reduce queries readability. Do you have a dinosaur programmer in your team that advertise this as a poor way to avoid errors ? For these two "features", trust unit test, static code analysis and continuous integration to detect errors, not programming practices from the 70s. Third, why the table sogo_folder_info replicates the credentials of the database in each record ? (columns c_location, c_quick_location, c_acl_location) Even if you wanted to have multiple database, the credentials should not be stored in clear text in the database. This is both a security issue and the worst database design I have seen so far...just remove this feature. Fourth, in the same table, what are the columns c_path1, c_path2, c_path3 ??? If your database was properly designed, you wouldn't need these artefacts. For 2022, can you hire a database administrator to redesign your database schema ? Otherwise, I wish the whole team a happy new year. Andre Rodier. -- users@sogo.nu https://inverse.ca/sogo/lists
