#013668: Improvement to eZContentObject->fetchAttributesByIdentifier()

Description:

There are two improvements being made:

Support for requesting an array of locale-codes, useful if you want to fetch multiple translations in one query, rather than doing one query per translation.
use eZDBInterface's generateSQLINStatement() to have a fully DB-independent query made.

Environment:

Operating System:
PHP Version: (please be specific, like '4.4.3' or '5.1.5')
Database and version:
Browser (and version):

Attachments

No attachments for this issue.

Comments

This affects BC, in that the 3rd parameter is now either false (for fetching most prioritized translation) or an array of the language codes to be fetchen.

Previously this parameter was a string for desired locale code.

#258291 by Ole Marius Smestad on September 26th, 2008 [Permanent Link]

Fixed in
trunk rev. 22392
stable/4.0 rev. 22393-22394

#258295 by Ole Marius Smestad on September 26th, 2008 [Permanent Link]

Is it difficult to keep accepting a string as well for the last parameter?

#258296 by Kristof Coomans on September 26th, 2008 [Permanent Link]

From a first look at the code I don't think it's a big hassle to keep BC, by handling both strings or arrays as valid arguments. So I suggest to fix this BC break.

#258298 by Kristof Coomans on September 26th, 2008 [Permanent Link]

I disagree here Kristof. It would be possible to support two kinds of parameters, but do we really want to?

The change here is intended, to keep the method as concise and unambiguous as possible. It is a also relatively new method, which is meant for use inside the kernel. Besides reading API documentation for parameters, which can be either of this type, or this type, is not the direction I think we ought to be going for our API.

In this case, I think it is acceptable tradeoff, that is, a change to the API, in order to solve a potential performance issue.

However for various reason it is not practical to mark it as a private method. But we should maybe have a way of marking methods which are not intended for public use, ala PHPDoc's @internal flag.

#258302 by Ole Marius Smestad on September 26th, 2008 [Permanent Link]

I agree that having mixed types of parameters is a bad practice. But breaking BC is as well, if there's no major reason for breaking it.

From what I can see from the svn log files, is that this method is about 10 months old. I think that's enough time to have some people using it. In this situation it's very easy to keep BC, so I think it shouldn't be broken.

Regarding the visibility of this method, I don't see any reason why it shouldn't be used publicly and only by the kernel. Can you clarify this?

#258303 by Kristof Coomans on September 26th, 2008 [Permanent Link]

Unintentional BC-breaks are not good.

However intended API-changes, in order to keep the API leaner and clearer, where the target audience, can be notified in advance are less problematic. In this case I would almost always prefer a clearer API, it will also reduce the footprint of the code, which is usually always good. In the end this helps API- and code-rot from starting to build up where it does not need to.

Regarding the visibility, that is a discussion which should be held elsewhere.

#258307 by Ole Marius Smestad on September 26th, 2008 [Permanent Link]

After discussion, a BC-fallback has been added for the language parameter in stable/4.0. In 4.1 this parameter will only accept an array.

Changed in:
stable/4.0 rev. 22411

#258357 by Ole Marius Smestad on October 1st, 2008 [Permanent Link]

Links

Reference

This issue relates to:

~~#013492~~

http link's are lost from content after deleting older version's of multi lingual content object.

History

Load History

Properties

Type		Enhancement

Priority		Medium

Components		Content (images, XML, PDF, RSS, etc.) Database related Documentation

Affects		4.0.1 - 4.0.1release

Fix Versions		4.0.2 4.1.0alpha1

Reporter		Ole Marius Smestad

Responsible		Ole Marius Smestad

Status		Docs Required

Resolution		Implemented

Created		September 26th, 2008

Updated		October 1st, 2008

Resolved		September 26th, 2008