I recently updated from Wagtail 2.13.5 to 3.0.3. After the update, the search() method on Wagtail's PageQuerySet returns no results for search terms that clearly should return results (and which do when using the older version).
For example, under 2.13, where search_backend is an instance of wagtail.contrib.postgres_search.backend.PostgresSearchBackend, and qs is an instance of wagtail.core.query.PageQuerySet the following returns lots of results:
search_backend.search('popular-search-term', qs, fields=None, operator=None, order_by_relevance=True, partial_match=True)
But under 3.0.3, where search_backend is now an instance of wagtail.search.backends.database.postgres.postgres.PostgresSearchBackend and qs is an instance of wagtail.query.PageQuerySet, the same call to search() will return nothing (an empty queryset).
The data in the qs queryset is the same in both cases, so maybe I'm missing something in my configuration of the search backend? My "settings.py" file has:
WAGTAILSEARCH_BACKENDS = {
'default': {
'BACKEND': 'wagtail.search.backends.database',
'SEARCH_CONFIG': 'english',
},
}
and
INSTALLED_APPS = [
...
'wagtail.search',
'wagtail.search.backends.database.postgres',
...
]
I had to guess at the value for 'wagtail.search.backends.database.postgres'. AFAICT, Wagtail's docs don't mention what should go into INSTALLED_APPS. But the pre-upgrade value of 'wagtail.contrib.postgres_search' would clearly be wrong, as that module has been removed.
Anyone got an idea why calling search() on a PageQuerySet would incorrectly return no results?
The steps for changing the search backend are documented at https://docs.wagtail.org/en/stable/releases/2.15.html#database-search-backends-replaced. In particular:
You should remove wagtail.contrib.postgres_search from INSTALLED_APPS, and do not need to add anything in its place - the existing wagtail.search app is sufficient
After changing over, you need to re-run the ./manage.py update_index command to ensure that the new search index is populated.
Related
I inherited an old TYPO3 Extension using SOBE. As far as I unterstand it's deprecated, but it seems there is no documentation on how to replace it.
The Extension is using Backend Forms and the following line is throwing an error:
if (is_array($GLOBALS['SOBE']->editconf['tt_content']) && reset($GLOBALS['SOBE']->editconf['tt_content']) === 'new') {
The error is:
Cannot access protected property TYPO3\CMS\Backend\Controller\EditDocumentController::$editconf
The Var $GLOBALS['SOBE'] is still there, and there is also editconf, but it's not working.
How can I replace this code or rewrite it?
The SOBE object is part by part removed since years. As there are multiple ways for using it - see https://docs.typo3.org/c/typo3/cms-core/main/en-us/search.html?q=sobe&check_keywords=yes&area=default - you may need to take a closer look what is the exact part of replacing this code.
I would guess you can see more at https://docs.typo3.org/c/typo3/cms-core/main/en-us/Changelog/9.2/Deprecation-84195-ProtectedMethodsAndPropertiesInEditDocumentController.html?highlight=editconf.
I love testing-library, have used it a lot in a React project, and I'm trying to use it in an Angular project now - but I've always struggled with the enormous error output, including the HTML text of the render. Not only is this not usually helpful (I couldn't find an element, here's the HTML where it isn't); but it gets truncated, often before the interesting line if you're running in debug mode.
I simply added it as a library alongside the standard Angular Karma+Jasmine setup.
I'm sure you could say the components I'm testing are too large if the HTML output causes my console window to spool for ages, but I have a lot of integration tests in Protractor, and they are SO SLOW :(.
I would say the best solution would be to use the configure method and pass a custom function for getElementError which does what you want.
You can read about configuration here: https://testing-library.com/docs/dom-testing-library/api-configuration
An example of this might look like:
configure({
getElementError: (message: string, container) => {
const error = new Error(message);
error.name = 'TestingLibraryElementError';
error.stack = null;
return error;
},
});
You can then put this in any single test file or use Jest's setupFiles or setupFilesAfterEnv config options to have it run globally.
I am assuming you running jest with rtl in your project.
I personally wouldn't turn it off as it's there to help us, but everyone has a way so if you have your reasons, then fair enough.
1. If you want to disable errors for a specific test, you can mock the console.error.
it('disable error example', () => {
const errorObject = console.error; //store the state of the object
console.error = jest.fn(); // mock the object
// code
//assertion (expect)
console.error = errorObject; // assign it back so you can use it in the next test
});
2. If you want to silence it for all the test, you could use the jest --silent CLI option. Check the docs
The above might even disable the DOM printing that is done by rtl, I am not sure as I haven't tried this, but if you look at the docs I linked, it says
"Prevent tests from printing messages through the console."
Now you almost certainly have everything disabled except the DOM recommendations if the above doesn't work. On that case you might look into react-testing-library's source code and find out what is used for those print statements. Is it a console.log? is it a console.warn? When you got that, just mock it out like option 1 above.
UPDATE
After some digging, I found out that all testing-library DOM printing is built on prettyDOM();
While prettyDOM() can't be disabled you can limit the number of lines to 0, and that would just give you the error message and three dots ... below the message.
Here is an example printout, I messed around with:
TestingLibraryElementError: Unable to find an element with the text: Hello ther. This could be because the text is broken up by multiple elements. In this case, you can provide a function for your text matcher to make your matcher more flexible.
...
All you need to do is to pass in an environment variable before executing your test suite, so for example with an npm script it would look like:
DEBUG_PRINT_LIMIT=0 npm run test
Here is the doc
UPDATE 2:
As per the OP's FR on github this can also be achieved without injecting in a global variable to limit the PrettyDOM line output (in case if it's used elsewhere). The getElementError config option need to be changed:
dom-testing-library/src/config.js
// called when getBy* queries fail. (message, container) => Error
getElementError(message, container) {
const error = new Error(
[message, prettyDOM(container)].filter(Boolean).join('\n\n'),
)
error.name = 'TestingLibraryElementError'
return error
},
The callstack can also be removed
You can change how the message is built by setting the DOM testing library message building function with config. In my Angular project I added this to test.js:
configure({
getElementError: (message: string, container) => {
const error = new Error(message);
error.name = 'TestingLibraryElementError';
error.stack = null;
return error;
},
});
This was answered here: https://github.com/testing-library/dom-testing-library/issues/773 by https://github.com/wyze.
I am building an extension with a backend module. When I call the findAll() method it returns a "QueryResult" object.
I tried to retrieve objects with findByUid() and it does work.
I set the storage pid in the typoscript:
plugin.tx_hwforms.persistence.storagePid = 112
I can also see it in the typoscript object browser.
I also added this to my repository class:
public function initializeObject()
{
$defaultQuerySettings = $this->objectManager->get(\TYPO3\CMS\Extbase\Persistence\Generic\Typo3QuerySettings::class);
$defaultQuerySettings->setRespectStoragePage(false);
$this->setDefaultQuerySettings($defaultQuerySettings);
}
so that the storage pid is ignored ...
It's still not working, findAll doesn't return an array of entites as it should
Repository must return a QueryResult from the findAll methods. Only methods which return a single object (findOneByXYZ) will return anything else.
All of the following operations will cause a QueryResult to load the actual results it contains. Until you perform one of these, no results are loaded and debugging the QueryResult will yield no information except for the original Query.
$queryResult->toArray();
$queryResult->offsetGet($offset); and $queryResult[$offset];
$queryResult->offsetExists($offset);
$queryResult->offsetSet($offset, $value); and $queryResult[$offset] = $value; (but be aware that doing this yourself with a QueryResult is illogical).
$queryResult->offsetUnset($offset); and unset($queryResult[$offset]); (again, illogical to use this yourself)
$queryResult->current(), ->key(), ->next(), ->prev(), ->rewind() and ->valid() which can all be called directly or will be called if you begin iterating the QueryResult.
Note that ->getFirst() and ->count() do not cause the original query to fire and will not fill results if they are not already filled. Instead, they will perform an optimised query.
Summa summarum: when you get a QueryResult you must trigger it somehow, which normally happens when you begin to render the result set. It is not a prefilled array; it is a dynamically filled Iterator.
This should work.there must be issue with your storage page in FindAll() extbase check for storage but in findByXXX() it ignore storage.
$objectManager = \TYPO3\CMS\Core\Utility\GeneralUtility::makeInstance('TYPO3\\CMS\Extbase\\Object\\ObjectManager');
$querySettings = $objectManager->get('TYPO3\\CMS\\Extbase\\Persistence\\Generic\\Typo3QuerySettings');
$querySettings->setRespectStoragePage(FALSE);
$this->cityRepository->setDefaultQuerySettings($querySettings);
$cities = $this->cityRepository->findAll();
Use additionally typoscript module configuration, like
module.tx_hwforms.persistence.storagePid = 112
Ensure your Typoscript is loaded in root. For BE modules I prefere to use
EXT:hwforms/ext_typoscript_setup.txt
where you write your module and extbase configuration.
Try to debbug like below and check findAll() method present for this repositry. I think this is useful for you click here
\TYPO3\CMS\Extbase\Utility\DebuggerUtility::var_dump(get_class_methods($this->yourRepositryName)); exit();
Afetr added all your changes once you need to uninsatll/install extension.
I would inspect the generated query itself. Configure the following option in the install tool:
$GLOBALS["TYPO3_CONF_VARS"]["sqlDebug"]
Note: dont do this in production environemnt!!
Explanation for sqlDebug:
Setting it to "0" will avoid any information being print on screen.
Setting it to "1" will show errors only.
Setting it to "2" will print all queries on screen.
So in Production you want to keep it at "0", in development environments you should set it to "1", if you want to know why some result is empty, configure it to "2".
I would guess that some enablefield configuration causes your problem.
If you retrieve an object by findByUid you will have the return because enablefields are ignored. In every other case enablefields are applied and that may cause your empty result.
My question is this: How can you implement a default server-side "filter" for a navigation property?
In our application we seldom actually delete anything from the database. Instead, we implement "soft deletes" where each table has a Deleted bit column. If this column is true the record has been "deleted". If it is false, it has not.
This allows us to easily "undelete" records accidentally deleted by the client.
Our current ASP.NET Web API returns only "undeleted" records by default, unless a deleted argument is sent as true from the client. The idea is that the consumer of the service doesn't have to worry about specifying that they only want undeleted items.
Implementing this same functionality in Breeze is quite simple, at least for base entities. For example, here would be the implementation of the classic Todo's example, adding a "Deleted" bit field:
// Note: Will show only undeleted items by default unless you explicitly pass deleted = true.
[HttpGet]
public IQueryable<BreezeSampleTodoItem> Todos(bool deleted = false) {
return _contextProvider.Context.Todos.Where(td => td.Deleted == deleted);
}
On the client, all we need to do is...
var query = breeze.EntityQuery.from("Todos");
...to get all undeleted Todos, or...
var query = breeze.EntityQuery.from("Todos").withParameters({deleted: true})
...to get all deleted Todos.
But let's say that a BreezeSampleTodoItem has a child collection for the tools that are needed to complete that Todo. We'll call this "Tools". Tools also implements soft deletes. When we perform a query that uses expand to get a Todo with its Tools, it will return all Tools - "deleted" or not.
But how can I filter out these records by default when Todo.Tools is expanded?
It has occurred to me to have separate Web API methods for each item that may need expanded, for example:
[HttpGet]
public IQueryable<Todo> TodoAndTools(bool deletedTodos = false, bool deletedTools = false)
{
return // ...Code to get filtered Todos with filtered Tools
}
I found some example code of how to do this in another SO post, but it requires hand-coding each property of Todo. The code from the above-mentioned post also returns a List, not an IQueryable. Furthermore this requires methods to be added for every possible expansion which isn't cool.
Essentially what I'm looking for is some way to define a piece of code that gets called whenever Todos is queried, and another for whenever Tools is queried - preferably being able to pass an argument that defines if it should return Deleted items. This could be anywhere on the server-side stack - be it in the Web API method, itself, or maybe part of Entity Framework (note that filtering Include extensions is not supported in EF.)
Breeze cannot do exactly what you are asking for right now, although we have discussed the idea of allowing the filtering of "expands", but we really need more feedback as to whether the community would find this useful. Please add this to the breeze User Voice and vote for it. We take these suggestions very seriously.
Moreover, as you point out, EF does not support this.
But... what you can do is use a projection instead of an expand to do something very similar:
public IQueryable<Object> TodoAndTools(bool deleted = false
,bool deletedTools = false) {
var baseQuery = _contextProvider.Context.Todos.Where(td => td.Deleted == deleted);
return baseQuery.Select(t => new {
Todo: t,
Tools: t.Tools.Where( tool => tool.Deleted = deletedTools);
});
}
Several things to note here:
1) We are returning an IQueryable of Object instead of IQueryable of ToDo
2) Breeze will inspect the returned payload and automatically create breeze entities for any 'entityTypes' returned (even within a projection). So the result of this query will be an array of javascript objects each with two properties; 'ToDo' and 'Tools' where Tools is an array of 'Tool' entities. The nice thing is that both ToDo and Tool entities returned within the projection will be 'full' breeze entities.
3) You can still pass client side filters based on the projected property names. i.e.
var query = EntityQuery.from("TodoAndTools")
.where("Todo.Description", "startsWith", "A")
.using(em);
4) EF does support this.
I'm doing the following using Mongoose:
that.model.update({_id: dao._id}, dao, { upsert: true }, cb);
Where dao is a mongoose representation containing (among other things) a couple of embedded documents. As a test I've deleted a couple of the embedded docs from the array before calling the update-method above.
The result is that the change to the array of embedded docs IS NOT persisted.
Anything I'm overlooking?
Hard to be certain w/o seeing more code, but if dao is a Mongoose model instance, you should be calling dao.save(cb); instead.
I solved the problem by doing something similar as proposed in the following issue: https://github.com/LearnBoost/mongoose/issues/571
For completeness some background which led to the problem.
I'm using DDD repositories which are populated on app-start. Under the hood this fetches Mongoose-objects (which are treate as DAOs in my situation) and are translated to domainobjects, which are cached in the repository. I need this separation between domainobjects and mongoose-objects, don't ask.
This means that getById, getAll and all other public interfaces of the repo work with domainobjects and not with mongoose-objects.
When doing things like add or update on the repo this internally only updates the in-mem cache (which, again, only uses domainobjects instead of mongoose-objects)
Only when doing commit on the repo does the possibly changed collection of domainobjects get persisted. This is done by creating NEW Mongoose-objects instead of fetching Existing mongoose-objects and updating those.
This is why I can't use dao.save() since, when I'm saving a different (just created) mongoose-object while a mongoose-object with the same id may possibly already exist in Mongo, it throws a duplicate id error.
Some relevant snippet from by code illustrating the solution:
var dao = that.createDAO(domainobject);
//https://github.com/LearnBoost/mongoose/issues/571
// Convert the Model instance to a simple object using Model's 'toObject' function
// to prevent weirdness like infinite looping...
var upsertData = dao.toObject();
// Delete the _id property, otherwise Mongo will return a "Mod on _id not allowed" error
delete upsertData._id;
that.model.update({_id: dao._id}, upsertData, { upsert: true }, cb);