Field imagepos on #__contact_details
84.le0n
I've received a bug report as you can see from this mail
http://groups.google.com/group/joomlabugsquad/msg/8b824f7efcd81c88
about an error on Postgresql installation, but it's related to
"imagepos" field of #__contact_details table.
This field is never used inside "Contact Manager: Contact" form, never
read nor write.
It's reasonable to cut it from table definition or it's used elsewhere?
Thank you,
Eng. Gabriele Pongelli.
Sam Moffatt
removal or flagged for removal it may be used by third party
extensions which could break with it's removal in general. Probably
just needs to be flagged for deletion and scheduled for removal with
CMS 3.0 since it permits backwards incompatible changes.
Cheers,
Sam Moffatt
http://pasamio.id.au
> --
> You received this message because you are subscribed to the Google Groups "Joomla! CMS Development" group.
> To post to this group, send an email to joomla-...@googlegroups.com.
> To unsubscribe from this group, send email to joomla-dev-cm...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>
84.le0n
> It may not be used in the core but as the field hasn't been marked for
> removal or flagged for removal it may be used by third party
> extensions which could break with it's removal in general. Probably
> just needs to be flagged for deletion and scheduled for removal with
> CMS 3.0 since it permits backwards incompatible changes.
How is it possible to schedule that removal ?
Eng. Gabriele Pongelli
elin
84.le0n
Il giorno 16/apr/2012, alle ore 09:31, elin <elin....@gmail.com> ha scritto:
> What is the problem it is causing?
>
> Elin
>
Look at
https://groups.google.com/d/msg/joomlabugsquad/LWQ0zyZ9PMg/UJqcyCXTXwIJ
The problem was reported on 15th of April and follows my answer.
Eng. Gabriele Pongelli
AVVERTENZE AI SENSI DEL D.LGS. 196/2003
Le informazioni contenute in questo messaggio di posta elettronica e negli eventuali files allegati, sono da considerarsi strettamente riservati. Il loro utilizzo è consentito esclusivamente al destinatario del messaggio, per le finalità indicate nel messaggio stesso. Qualora riceveste per errore questo messaggio, Vi preghiamo cortesemente di darcene notizia all'indirizzo e-mail di cui sopra e di procedere alla distruzione del messaggio stesso, cancellandolo dal Vostro sistema; costituisce comportamento contrario ai principi dettati dal D.lgs. 196/2003 il trattenere il messaggio stesso, divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od utilizzarlo per finalità diverse.
This electronic transmission is strictly confidential and intended solely for the addresses. It may contain information which is covered by legal, professional or other privilege. If you are not the intended addressee, you must not disclose, copy or take any action in reliance of this transmission. If you have received this transmission in error, please notify us and delete the received data as soon as possible
Sam Moffatt
through 78 individual posts with disjointed threading, you wouldn't
mind posting a summary?
Cheers,
Sam Moffatt
http://pasamio.id.au
84.le0n
Il giorno 16/apr/2012, alle ore 11:33, Sam Moffatt <pas...@gmail.com> ha scritto:
> In the interests of being able to find the issue without having to dig
> through 78 individual posts with disjointed threading, you wouldn't
> mind posting a summary?
>
Sam, I'm sorry but I'm on mobile and I can't link you exact post on that discussion.
Trying to sum up, there's a field inside a table never used inside cms and platform that is fixed to be 20 character long.
This field is filled with 'NULL::character varying' string inside it's JTable::store class (this is first error, it must me NULL and not a string and I don't know where is taken this string) and that string is longer than 20, so it's shown an error.
A first solution could be to check this field and force to null, but better (or even the best) one is to remove it because never user (or at least mark as deprecated and remove it before Postgresql inclusion).
That's all.
elin
84.le0n
Have I to cut it from my Postgresql branch?
Eng. Gabriele Pongelli
elin
brian teeman
On Wednesday, 18 April 2012 00:47:29 UTC+1, elin wrote:
Can you just change the definition to something that doesn't cause problems? No one using postgres is going to have any old data anyway.
Sam Moffatt
postgres specific. I can't imagine why we'd insert what looks like a
PostgreSQL field type into a field randomly.
Cheers,
Sam Moffatt
http://pasamio.id.au
elin
> To post to this group, send an email to joomla-dev-cms@googlegroups.com.
> To unsubscribe from this group, send email to joomla-dev-cms+unsubscribe@googlegroups.com.
brian teeman
On Wednesday, 18 April 2012 05:09:17 UTC+1, elin wrote:
But realistically, how many extentions for 2.5 that are supporting postgres are going to be using a 1.0 field? Any extension that has multidb support is, I would say, pretty up to date and unlikely to be doing something like storing some information in the contact table.
elin
Sam Moffatt
working fine on MySQL isn't working fine on PostgreSQL because it's
being stuffed with a PostgreSQL field name. To me that is the more
worrying issue because someone else might legitimately have a need for
what ever this is doing.
Cheers,
Sam Moffatt
http://pasamio.id.au
>>>> > joomla-...@googlegroups.com.
>>>> > To unsubscribe from this group, send email to
>>>> > joomla-dev-cm...@googlegroups.com.
>>>> > For more options, visit this group at
>>>> > http://groups.google.com/group/joomla-dev-cms?hl=en-GB.
>>>> >
>
> --
> You received this message because you are subscribed to the Google Groups
> "Joomla! CMS Development" group.
> To view this discussion on the web, visit
> https://groups.google.com/d/msg/joomla-dev-cms/-/Xq7Pxvs2wE0J.
>
> To post to this group, send an email to joomla-...@googlegroups.com.
> To unsubscribe from this group, send email to
> joomla-dev-cm...@googlegroups.com.
84.le0n
(now I'm not writing with my phone).
The error reported is
JLIB_DATABASE_QUERY_FAILED ERROR: value too long for type character varying(20)
and the pair column-value inside "UPDATE #__contact_details SET ... "
query that generate this error is
"imagepos"='NULL::character varying'
This column is never handled inside cms nor inside platform, it's
defined inside postgresql's joomla.sql as
"imagepos" character varying(20) DEFAULT NULL,
and, assigning to it a string like 'NULL::character varying' (23
character) returns this error.
Now big problem is why this query uses
"imagepos"='NULL::character varying'
and not
"imagepos"=NULL::character varying
as it could be expected with that definition.
so where is that quote added?
I've used cms to search what is showed to user by that field but I
haven't found it, so searching I've found that it's never used and
finally I've started this thread to ask if someone knows where it's
used or if it's possible to remove it.
To get this error with PostgreSQL you've to go on "Contact
Manager:Contact" form.
Thanks,
Eng. Gabriele Pongelli.
Sam Moffatt
to begin with?
Cheers,
Sam Moffatt
http://pasamio.id.au
84.le0n
> Ignoring why it's quoted, where is the NULL::character varying added
> to begin with?
>
> Cheers,
>
> Sam Moffatt
> http://pasamio.id.au
The association of "NULL::character varying" with "imagepos" field is
done inside JTable::reset coming from its definition
"imagepos" character varying(20) DEFAULT NULL
The problem is that executing same query without quoting
'NULL::character varying' it'll be set correctly to null, doing quote
it'll be treated like a string and beat with length constraint.
Possible solutions are:
- delete this files (I've already added a comment to deprecate this
field inside mysql and postgresql)
- make it bigger (at least 23 characters) so length constraint will not be met
- change its definition to empty string
Which of them could be better ?
This error was found because that field isn't matched with any form
value, because all other fields' value with same definition (longer
character value with default null) are overwritten by form value.
Eng. Gabriele Pongelli
elin
84.le0n
> It's no big deal to change the size, that seems like the easiest solution
> for the short term.
>
> Elin
Pushed a change to use 50 character .
Eng. Gabriele Pongelli .
Sam Moffatt
may not be necessary, it seems like we're avoiding fixing a problem
which a third party developer could encounter.
Does this mean that the field will literally be filled with the text
"NULL::character varying" instead of an actual null?
Cheers,
Sam Moffatt
http://pasamio.id.au
84.le0n
> Does this mean that the field will literally be filled with the text
> "NULL::character varying" instead of an actual null?
>
> Cheers,
>
> Sam Moffatt
> http://pasamio.id.au
Quoting its default value (NULL::character varying) will fire this error because it's threaded like a string and not like null.
Without quoting the field will correctly filled with null value.
This fix is temporary, because that field will be erased in future.
Sam Moffatt
an actual use case identical to this. The fix isn't temporary, it's a
workaround to avoid fixing what ever the root cause of the problem.
I still don't understand how something PostgreSQL specific is seeping
into this field. It very much feels like a bug with the PostgreSQL
driver's insertObject/updateObject code.
So why don't we fix the actual problem?
Cheers,
Sam Moffatt
http://pasamio.id.au
84.le0n
> But someone else might be working on a third party extension that has
> an actual use case identical to this. The fix isn't temporary, it's a
> workaround to avoid fixing what ever the root cause of the problem.
>
> I still don't understand how something PostgreSQL specific is seeping
> into this field. It very much feels like a bug with the PostgreSQL
> driver's insertObject/updateObject code.
>
> So why don't we fix the actual problem?
>
> Cheers,
>
> Sam Moffatt
> http://pasamio.id.au
I'm with you when you tell that this is a workaround, but what do you
mean with "actual problem" ?
Why are you pointing your attention to insertObject/updateObject ?
I think some solution could be to change its definition to have a
default empty string, or change postgresql's quoteName function to
deny quoting of strings like "NULL::"
Eng. Gabriele Pongelli
Sam Moffatt
doesn't do this on MySQL…
Like can you link me to the line of code where "NULL::character
varying" gets set as the field value. I'm not understanding this. I've
asked so many questions but I still understand why something that
doesn't happen on MySQL is randomly happening for you on PostgreSQL.
The reason I point to insertObject/updateObject is because when JTable
goes off to serialise things that's what it uses. Since I have no idea
what is trigger the problem or how or where beyond your repeated
assertions that it is that's where I'm looking. Tell me where I should
be looking.
Cheers,
Sam Moffatt
http://pasamio.id.au
84.le0n
> How does the field get the text "NULL::character varying" in it? It
> doesn't do this on MySQL…
I told you this period one day ago:
The association of "NULL::character varying" with "imagepos" field is
done inside JTable::reset coming from its definition "imagepos"
character varying(20) DEFAULT NULL
I told this because during "save" task it's created a
ContactTableContact object, it calls
$this->reset()
inside JTable::load() that will create all the JTable parameters
coming from each table field, obtained from query, and associate each
default value to each field.
That "NULL::character varying" comes from field's definition: this
particular format means "take null and cast as character varying"
because definition tells to have null as default of a character
varying field, it's returned from query I do in
JPostgresqlDatabase::getTableColumns called by JTable::getFields() .
So
JTable::getFields calls JPostgresqlDatabase::getTableColumns ,
JPostgresqlDatabase::getTableColumns execute a query that returns
"NULL::character varying" as default value for "imagepos" field.
Is it now clearer than before?
> Like can you link me to the line of code where "NULL::character
> varying" gets set as the field value. I'm not understanding this. I've
> asked so many questions but I still understand why something that
> doesn't happen on MySQL is randomly happening for you on PostgreSQL.
libraries/joomla/database/table.php , reset member, line 411 , here it
sets "NULL::character varying" as default value.
Eng. Gabriele Pongelli
Sam Moffatt
returning a string instead of a null?
Cheers,
Sam Moffatt
http://pasamio.id.au
84.le0n
> So what you're saying is that getFields from the database driver is
> returning a string instead of a null?
Could be reasonable to confirm this.
getFields returns row with "Default" column set to a string instead of nothing.
Eng. Gabriele Pongelli
Sam Moffatt
for when the default is "NULL::character varying" which matches to the
PHP type and should then work properly (presumably
insertObject/updateObject might need to handle it since update nulls
could be set, not sure without digging through entirely)?
Cheers,
Sam Moffatt
http://pasamio.id.au
84.le0n
> So if that is the case, can we update that behaviour to return a null
> for when the default is "NULL::character varying" which matches to the
> PHP type and should then work properly (presumably
> insertObject/updateObject might need to handle it since update nulls
> could be set, not sure without digging through entirely)?
>
> Cheers,
>
> Sam Moffatt
> http://pasamio.id.au
- defining "imagepos" as "NULL::character varying" lead to have this
error of exceeding length
- defining "imagepos" as "''::character varying" lead to have
"imagepos" filled with empty string
- not defining "imagepos" lead to have null value inside that field
Maybe I've to change definition of all character varying fields that
need to be null, changing their definition from "NULL:: ... " to
nothing.
So what do you suggest?
Eng. Gabriele Pongelli
Sam Moffatt
So it occurs in the reset method:
https://github.com/joomla/joomla-cms/blob/master/libraries/joomla/database/table.php#L403
That calls JTable::getFields and iterates over the result and sets
each of the keys to be the value of the "Default" member on line 411:
https://github.com/joomla/joomla-cms/blob/master/libraries/joomla/database/table.php#L411
JTable::getFields is defined on line 124:
https://github.com/joomla/joomla-cms/blob/master/libraries/joomla/database/table.php#L124
We can see that it caches the field list and reaches out to the
database on line 132 to get the table columns:
https://github.com/joomla/joomla-cms/blob/master/libraries/joomla/database/table.php#L132
Borrowing the MySQL implementation, getTableColumns is defined on line 358:
https://github.com/joomla/joomla-cms/blob/master/libraries/joomla/database/database/mysql.php#L358
We can see it executes the SQL "SHOW FULL COLUMNS FROM tablename" on line 363:
https://github.com/joomla/joomla-cms/blob/master/libraries/joomla/database/database/mysql.php#L363
It does some other processing as well but doesn't appear to touch the
"Default" column.
Running this on a MySQL install against the #__contact_details table
gives us the following definition for the imagepos column:
Field: imagepos
Type: varchar(20)
Collation: utf8_general_ci
Null: YES
Key:
Default: (NULL)
Extra :
Privileges: select,insert,update,references
Comment:
Now I know from experience with the MySQL driver that it will
translate the NULL value for that field into a NULL value in the data
type.
The fix should be to change the PostgreSQL driver to return a literal
null if the default value of the column is a null similar to how the
MySQL driver behaves in it's definition of getTableColumns. I don't
understand why we can't detect in here that if the default is a null
of any type why we can't just return a null?
84.le0n
> I'm confused why the field type is being set as the default value for the field.
> https://github.com/joomla/joomla-cms/blob/master/libraries/joomla/database/database/mysql.php#L363
>
> It does some other processing as well but doesn't appear to touch the
> "Default" column.
> Running this on a MySQL install against the #__contact_details table
> gives us the following definition for the imagepos column:
>
> Field: imagepos
> Type: varchar(20)
> Collation: utf8_general_ci
> Null: YES
> Key:
> Default: (NULL)
> Extra :
> Privileges: select,insert,update,references
> Comment:
>
>
> Now I know from experience with the MySQL driver that it will
> translate the NULL value for that field into a NULL value in the data
> type.
manually and tried to add all default values and it goes ok, so now
I've a row with null on "imagepos" column.
It's really strange...
I'll investigate deeply repeating this with an installation.
> The fix should be to change the PostgreSQL driver to return a literal
> null if the default value of the column is a null similar to how the
> MySQL driver behaves in it's definition of getTableColumns. I don't
> understand why we can't detect in here that if the default is a null
> of any type why we can't just return a null?
Eng. Gabriele Pongelli
84.le0n
issue, code follows
/* Change Postgresql's NULL::* type with PHP's null one */
foreach ($fields as $field)
{
if (preg_match("/^NULL::*/", $field->Default))
{
$field->Default = null;
}
}
This was because value previously returned by PostgreSQL were used as
string on PHP, and not as real null, this patch do conversion needed.
Thanks for useful discussion!
Eng. Gabriele Pongelli