Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Hi,
I wanted to use this module on Postgres, but your SQL query to fetch the next sequence number is MySQL-specific.
Patch attached for Postgres support.
Thanks
Comment | File | Size | Author |
---|---|---|---|
#20 | email_registration-6.x-1.x-unique_usernames-421078-20.patch | 4.37 KB | dwightaspinwall |
#17 | 421078_unique_usernames_17.patch | 3.58 KB | greggles |
#13 | 421078_unique_usernames_13.patch | 3.59 KB | greggles |
#12 | 421078_unique_usernames.patch | 3.76 KB | greggles |
#6 | email_registration_ansi_sql.patch | 2.9 KB | dwightaspinwall |
Comments
Comment #1
gregglesI don't have a test bed for this, but here's a better status ;)
Comment #2
gregglesThis is not a real solution to the problem because it uses a switch. We should use standard sql.
As far as I can tell, this code is trying to find 1) if the name is unique, 2) if not, what is the highest "index" for the name. While it may be slightly slower, we should be able to do more of this in php and make it cross-database compatible.
Comment #3
dspring0021 CreditAttribution: dspring0021 commentedIs there a solution to this. I'm running Drupal 6.19 and Email Registration 6.x-1.3 on PostgreSQL. I'm getting the errors below when registering a username of an email address that already exists in the db--as in the scenario outlined in this issue. The patch above failed. So, then, I tried to manually make the changes, but the code seems to be always using the mysql version of the query. I'm kind of stuck. Any advice on resolving this for pgsql would be much appreciated.
Comment #4
dspring0021 CreditAttribution: dspring0021 commented***UPDATE***
I lied in my post above. The patch does work for me (user error before). It will suffice as a workaround for now. Thank you!
Comment #5
dwightaspinwall CreditAttribution: dwightaspinwall commentedSubscribing. An ANSI sql solution would be nice. BTW, thanks for a great module - we use it on hci.org - 200,000 member site.
Comment #6
dwightaspinwall CreditAttribution: dwightaspinwall commentedHere's a patch for review. Should be cross-db compatible, eliminating the need for db-specific solutions.
Comment #7
dwightaspinwall CreditAttribution: dwightaspinwall commentedComment #8
thePanz CreditAttribution: thePanz commentedTested, working fine!
Comment #9
YK85 CreditAttribution: YK85 commentedfyi - #657472: Add setting to allow users to login with email address or username depends on this patch
Comment #10
thePanz CreditAttribution: thePanz commented@yaz085: to clarify your comment: the #657472-23: Add setting to allow users to login with email address or username patch includes this patch (it's not a dependency) ;) Maybe someone could work to split them (and then commit both) :)
Comment #11
gregglesWhy not just use trim?
Comment #12
gregglesHere's a rewrite/reroll for Drupal 7.
Using $new_name instead of $namenew - the standard in Drupal is to separate words in a variable by an underscore.
Using trim instead of preg_replace - seems likely that trim is faster and more thorough - http://maettig.com/code/php/php-performance-benchmarks.php backs up that perspective.
Perform the uniqueness check regardless of where the name comes from - this seems less likely to let a site-specific module or other contrib screw up the process.
Added some documentation about the need to validate the input to the function.
Flipped the do {} while loop so that a username can potentially come in with notting appended to the end. I don't see why the username should have to have something appended to the end.
Comment #13
gregglesLet's try that again :)
Updated for full d7 query style.
I realized that the existing code already handled letting through the username itself on the first pass when $i = 0 and is therefore empty.
Comment #14
gregglesIt would be great to get feedback on the patch in #13. I plan to commit it in ~2 weeks.
Comment #15
gregglesUpdated title, this is about more than just cross-db compatible business.
Comment #17
gregglesIt applied with "patch -p1" but not with "git apply". Rerolled and passes tests locally.
Comment #18
dwightaspinwall CreditAttribution: dwightaspinwall commentedThanks for your work on this greggles. Are you planning to roll a patch of same functionality for 6.x-1.x-dev or should I do it? Here or in separate issue?
Comment #19
greggles@dwightaspinwall - It would be lovely if you could review this and re-roll for 6.x-1.x. See #1878166: Create 7.x-1.1, 6.x-1.4 release for my general plan for 6.x. Most of these should be straightforward to re-roll for 6.x-1.x. It would be great if you could do some (or all) of that work.
Comment #20
dwightaspinwall CreditAttribution: dwightaspinwall commentedHere's a patch for 6.x-1.x based on #19. I've tested it, but probably deserves an independent test.
Comment #22
gregglesOK, committed to 7.x-1.x http://drupalcode.org/project/email_registration.git/commit/29d37d2
Let's see if the last one will pass the 6.x-1.x tests.
Comment #23
greggles#20: email_registration-6.x-1.x-unique_usernames-421078-20.patch queued for re-testing.
Comment #24
gregglesThanks, dwightaspinwall! Now committed http://drupalcode.org/project/email_registration.git/commit/56a2315 giving you credit as the author :)