Ouch. Probably partially my fault. Feel free to escalate this as Task under Bug Reports - close this as obsolete then
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
All Stories
Mar 25 2024
I can't immediately reproduce with that version either. I'll try again later.
In the meanwhile:
- Try clearing your browser's cache
- Try updating Phorge to the latest commit
- Try disabling this extension: assets/DisableUsernameEditEventListener.php
Implement the actual deep clone
I can reproduce this on master with basically any string search.
https://we.phorge.it just works fine. :L
- Phorge installation
I can't reproduce this.
Which version of phorge/arc do you have (git log -1)?
How did you install the new Instance?
Interesting. This cannot be reproduced here in this website https://we.phorge.it? isn't it? I think no
:p
(Please edit file Visibility to make them Public :D It's another bug ihih - thanks! <3)
remove unrelated stuff
Please also include your exact search. I think you are searching by https://foo and that is unfortunately not possible without "doing this"
Mar 24 2024
Ouch
Mar 23 2024
update testplan
fix linting issues
Continued work, now using proper transactions and beeing able to copy comments
Mar 22 2024
So I got this mostly working locally, it's actually fairly trivial to reuse the existing token storage and infrastructure. Actually displaying the tokens might not be the most efficient of operations when there are a lot of comments on a given object. I still need to write an optimized query to fetch all of the token given in one query rather than many and then figure out how to display the tokens inline with the comments.
Thanks for your answer. Yes, the restart item on the Build Plan display is also wrong then.
$ php --rf strpos Function [ <internal:standard> function strpos ] {
Mar 21 2024
Also note that we have a similar PhabricatorDataNotAttachedException in PhabricatorRepositoryCommit (via getRepository()) in downstream https://phabricator.wikimedia.org/T360714. It's without reproduction steps but sounds a bit similar.
In D25118#14541, @speck wrote:I forgot I had this requesting changes. Any idea of the performance hit in markup rendering now that PhutilURI is constructed for every link? I think its constructor does a fair amount.
Mar 20 2024
@avivey to do now:
The repo is set to "host" right now, but it can also be set to "observe from" or "mirror to" another repo.
Mar 19 2024
Sorry, I'm not explaining it very well. For the database engine to use index (col1, col2, col3), col1 must be specified somewhere in the WHERE clause, but it's precise location is irrelevant - the database engine will work it out. As to why we need both indexes, there's a good explanation on https://use-the-index-luke.com/sql/where-clause/the-equals-operator/concatenated-keys
Interesting, and a little troubling if I understand it correctly; It means that the query ... WHERE dst = $a and type = $b and src = $c will be a full-table-read, but the equivalent query src = $c and type = $b and dst = $a will use the index to resolve quickly?
minor optimization and unit tests are still happy
@avivey - the order of the keys is irrelevant when it comes to determining uniqueness, but extremely important in other respects. In order for an index to be used when selecting rows, the database must be provided with values for the index fields, in the order specified. Ie you always need to specify a value for the first field, and can get away without successive ones.
Are the keys actually different? Looks like they have the same fields in different order. Does this makes a difference in the implementation?
Mar 18 2024
@valerio.bozzolan agreed - I'm not proposing to remove the (dst, type, src) index, just the uniqueness constraint on that index. Sorry for not making that clear.
But in any case, it may have sense to keep a generic index on (dst, type, src) (or maybe just dst, type) in that specific order, since the UNIQUE KEY was probably a "micro-optimization" to achieve such index for queries operating on dst, or also dst and type, but all without src. This is just an opinion from an alien. Better to wait for more answers.
Mar 17 2024
Your email address(es) set by you for your user account in the Phorge Project
That is private data. Nobody can access it.
Mar 16 2024
I'm pretty sure getValueForQuery() should return some value?
I have a problem with this statement: