Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix EZP-26209: Textline legacy search indexing causes TransactionError #1338

Merged
merged 1 commit into from
Dec 21, 2017

Conversation

blankse
Copy link
Contributor

@blankse blankse commented Dec 19, 2017

Alternative to #1268

@blankse
Copy link
Contributor Author

blankse commented Dec 19, 2017

@andrerom I create the PR without your nitpic.

@andrerom andrerom requested a review from alongosz December 20, 2017 09:35
@andrerom
Copy link
Contributor

andrerom commented Dec 20, 2017

+1, but @alongosz; any input on if the max and min is within what most SQL engines support (given this is on generic interface).

*
* @var int
*/
public $MAX_INT = 2147483647;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like most reasonable limit supported by every DBMS out-of-the-box.

However these should be constants IMHO // cc @andrerom

@blankse
Copy link
Contributor Author

blankse commented Dec 20, 2017

@alongosz I changed it to constants

@pkamps
Copy link
Contributor

pkamps commented Dec 20, 2017

It's probably OK to use const. But in the unlikely case we would support a DBMS with different values for max/min integers we probably have a hard time to overwrite that value in a child class for that DBMS.
https://stackoverflow.com/questions/13613594/overriding-class-constants-vs-properties

@alongosz
Copy link
Member

@pkamps I wouldn't recommend overriding it at all as it would cause issues for data migrations between systems.
2^31 is a reasonable value that is supported by most of the DBMS-es if not all of them.

But if you really want to override it later, then property is also bad choice because those values are constant with respect to DBMS, not db handler instance. In this case introducing a method, e.g. getMaxInt would make more sense.

@andrerom andrerom added this to the 2017.12 milestone Dec 20, 2017
Copy link
Contributor

@andrerom andrerom left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1, but @pkamps are you fine with this? As stated above different lengths depending on sql engine will be an issue as well that blows up the complexity (for data migrations) vs use here as far as I can see.

@pkamps
Copy link
Contributor

pkamps commented Dec 21, 2017

+1
I'm convinced, it's very unlikely to have different int max/min values.

@gggeek
Copy link
Contributor

gggeek commented Dec 21, 2017

If going for a const, I vote for naming it MAX_INT_32BIT, so that it is slightly more clear what is intended purpose and origin are. Fe. it makes it easier to add later MAX_INT_64BIT and have code which uses the latter...

As a complement of info

  • php MAX_INT is already 64 bit almost everywhere (even on windows) and hence can not be used
  • all dbs supported by eZ also use 64 bits for ints and have done that since dawn of time
  • only 'db' that I know of currently stuck on 32bit land is Solr

@blankse blankse deleted the EZP-26209 branch November 29, 2018 14:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

Successfully merging this pull request may close these issues.

5 participants