| Package home | Report new bug | New search | Development Roadmap | Status: Open | Feedback | All | Closed Since Version 1.0.2 |
| Bug #5127 | crosslink fields don't work with pgsql | ||
|---|---|---|---|
| Submitted: | 2005-08-17 15:26 UTC | ||
| From: | jowenn at kde dot org | Assigned: | justinpatrin |
| Status: | Closed | Package: | DB_DataObject_FormBuilder |
| PHP Version: | 4.4.0 | OS: | linux |
| Roadmaps: | (Not assigned) | ||
[2005-08-17 15:26 UTC] jowenn at kde dot org
Description:
------------
I'm using postgresql 8.x and there the table names as they
are understood by the pear db layer and teh formbuilder
are created like "public.tablename"
This causes Problems, since form fields for crosslinked
tables are created like
__crossLink_public.siteuser_group_username_id
The page receives this as
__crossLink_public_siteuser_group_username_id in the post
request though ( . --> _).
The problem is solved, if in processForm the crosslink
name is generated like:
$crossLinkName = str_replace('.','_','__crossLink_'.
$crossLink['table'].
'_'.$crossLink['fromField'].
'_'.$crossLink['toField']);
(with the str_replace)
Could that be put into mainstream ?
Kind regards
Joseph Wenninger
Comments
[2005-08-17 16:42 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2005-08-17 16:44 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2005-08-17 18:05 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2005-08-19 09:49 UTC] jowenn at kde dot org
If only the "public" schema is used there is no problem to
put
generator_strip_schema = true
into the inifile for the generator
since "tablename" equals to "public.tablename", but if a
user uses schemas he has defined himself, he can't do
that.
I don't really see the problem, why it should be a
nightmare to maintain.
What about a function fixFieldNames or something like
that, through which all generated field names are passed
through before being put into the page or before being
checked for in post/get requests, which filters anything
but a-zA-Z0-9_ away and replaces the bad characters by "_"
A disadvantage would be a performance penalty ofcourse.
[2005-08-19 18:05 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!
[2005-08-22 04:55 UTC] User who submitted this comment has not confirmed identity
If you submitted this note, check your email.If you do not have a message, click here to re-send MANUAL CONFIRMATION IS NOT POSSIBLE. Write a message to pear-dev@lists.php.net to request the confirmation link. All bugs/comments/patches associated with this email address will be deleted within 48 hours if the account request is not confirmed!