I'm in the process of migrating from hibernate search 5 to 6. Many annotation classes that were present in hibernate search 5 have been completely removed in hibernate 6. One of these annotations was #Spatial. With this annotation you could configure which SpatialMode hibernate search should use when processing spatial information. For instance SpatialMode.HASH.
Now that #Spatial is gone, what is the proper way to set the spatial mode in hibernate 6?
I've already checked the documentation but it doesn't mention anything about spatial modes.
EDIT: I believe these are all the settings hibernate search has.
EDIT 2: I did find this property hibernate.search.backend.sharding.strategy that can be set to hash. Is this the property that i need to set?
There is a migration guide from Hibernate Search 5 to Hibernate Search 6
In this guide, there is a section about #Spatial
And in this section, there is a subsection about #Spatial.spatialMode:
#Spatial.spatialMode, #Spatial.topSpatialHashLevel, #Spatial.bottomSpatialHashLevel have no equivalent in Hibernate Search 6: geohash-based geo-point fields are no longer supported.
For Lucene, this is because Hibernate Search now uses Lucene’s built-in spatial support, which is range-based.
For Elasticsearch, hash-based geo-point fields have never been available in the first place.
Related
I am trying to get the mapping details like expressions used, KM used ,etc. Previously in 11g ,I was able to query it from SNP_POP and SNP_POP_MAPPING. However in 12c these tables are empty. What're the equivalent tables for these two in 12C?
I am trying to edit the KM's of specific mappings through SNP tables instead of writing a Groovy script.
Interfaces have been replaced by mappings in 12c. You will find the mappings metadata in SNP_MAPPING and all the tables starting with SNP_MAP_. It's a bit more complex than interfaces because there could be a lot more components and multiples target tables.
Here is an example of a query to retrieve the target table names of a mapping : https://www.rittmanmead.com/blog/2016/02/di-tips-odi12c-repo-query-mapping-target-table/
You can find the repository documentation in this article : Doc ID 1903225.1 : Oracle Data Integrator 11g and 12c Repository Description
However I would strongly recommend not to change the KMs from the repository. Select statements on the repositories are allowed but DML statement are not supposed to happen and are not supported by Oracle.
A groovy script using the SDK is definitely the way to go. Luckily, it's already written for you : http://www.ateam-oracle.com/getting-groovy-with-odi-upgrades-and-owb-migrations/
According to the release notes, Xcode 9 adds support for fetched indexes:
"The data model editor presents a unified interface for Core Data’s
new fetch indexes feature as well as its existing property index and
entity compound index features. Older data models are translated into
fetch index form for editing, and saved to the old file format when
necessary. Compiling a data model with a Deployment Target lower than
iOS 11, watchOS 4, macOS 10.13, or tvOS 11 continues to generate a
compatible compiled form. (30843153)"
My project has Deployment Target set to iOS 9 at the moment a yet I can't compile my CoreData model, it gives me the following errors for every entity that has a compound index set:
Model.xcdatamodeld/Model.xcdatamodel:MyEntity|compoundIndex[0]: error: Expression requires a concrete result type.
Model.xcdatamodeld/Model.xcdatamodel:MyEntity|compoundIndex[0]: error: Expression attributes are not compatible with the current deployment target.
Model.xcdatamodeld/Model.xcdatamodel:MyEntity|compoundIndex[1]: error: Expression requires a concrete result type.
Model.xcdatamodeld/Model.xcdatamodel:MyEntity|compoundIndex[1]: error: Expression attributes are not compatible with the current deployment target.
Model.xcdatamodeld/Model.xcdatamodel:MyEntity: error: Fetch Indexes feature requires iOS deployment target 11.0 or later
Model.xcdatamodeld/Model.xcdatamodel:MyEntity: error: Fetch Indexes feature requires Xcode 9.0 tools or later
Any idea how to fix the build error?
UPDATE:
Xcode 9 correctly converts compound indexes into fetch indexes for all cases except those created from relationships, as noted in the "Known Issues" section:
The data model editor only supports creating fetch indexes from attributes and expressions in this beta, not from relationships. (32407895)
The affected fetch indexes look like this and the only attributes can be selected from the dropdown menu:
However, there's no workaround described in the document.
I just ran into this issue in the Xcode 9 GM. What I observed was that unchecking the Ascending checkbox in the index editor caused this error to occur (it was only showing up after I made a new index). I am assuming that adjusting this index attribute is only supported in the iOS 11 fetch indexes (you'll notice any index you made prior to Xcode 9 are listed as ascending by default).
TL;DR: Make sure the Ascending checkbox is checked for all properties in the fetch index editor.
This is fixed in Xcode 9 beta 2, according to the release notes:
The Xcode data model editor supports creating fetch indexes from
attributes, expressions, and relationships. (32407895)
I've filed a bug with Apple - as there doesn't seem to be a good fix. For now, I've changed the "Tools Version" from Automatic/Xcode 9 to Xcode 8. That fixed my problem until the bug is fixed.
Its also possible that some Models simply aren't compatible with the new indexes. In my case, it was subclassed models (i.e. from abstract classes) that had relationships to other types. For example:
PIFolder
|
|-----PIFolderProject -> index: defaultItem (task relationship)
|-----PIFolderNotebook-> index: defaultItem (note relationship)
I came here after getting
cdtool[0] Entity already has an index with name
While trying to upgrade base target to iOS 11.
After days of trial and error, the fix was to rename the index using a unique name
Prior to iOS 11 index names weren't unique, so I had 2 byRankIndex.
Changing them to unique names fixed it.
I am creating a blog like application using jHipster and want to support i18n in 2 languages (English and Chinese). The jHipster page on this (https://jhipster.github.io/installing-new-languages/) explains i18n on UI elements only.
But how to provide i18n support for values of entities? In this case I want Articles entity of blog to be in two languages.
One of the workaround would be to get the values in both languages from the user into separate entity fields and display accordingly. Is it a right approach?
JHipster does not provide any helper for content localization. This must be done at JPA/Hibernate level.
You can have a field per language or an entity per language where Article would have a one-to-many relationship with LocalizedArticle that would contain all localized fields using a Map<String, LocalizedArticle> using locale as map key.
There are other options which are presented in this good article.
This seems to be a mystery in cassandra, According to official documentation, one can create index on a column by using a custom indexer class
CREATE CUSTOM INDEX ON users (email) USING 'path.to.the.IndexClass';
But I could not find any documentation regarding the interface/class to be implemented/extended to do this and how to configure cassandra to find the class?
I wanted to write a custom indexer which could skip indexing rows based on conditions/options.
Here what I've found https://issues.apache.org/jira/browse/CASSANDRA-6480
So you have to implement a subclass of org.apache.cassandra.db.index.SecondaryIndex and make sure that class is on the classpath for your Cassandra
Here you can find example of implementation:
http://tuplejump.github.io/stargate/
https://github.com/tuplejump/stargate-core
Stratio's Cassandra Lucene Index is a plugin which supports custom indexes in cassandra, you can find the required documentation on how to work with custom indexes.
It's easier to generate tables and default classes with liferay's service builder.
But it is bit difficult for me to understand the hierarchy of classes generated by it.
Also the exact use of each class other than modifying LocalServiceImpl class as per our need by adding our own functionality.
I have gone through Service Builder doc. So I got some basic knowledge but would like to get more on this.
Even the link "Liferay Service Builder" was useful but outdated with current Liferay version. So Does anyone have update on above link or nice info explaining hierarchy with example/diagram?.
Any help is appreciated.
Thanks.
To implement the foreign key concept in liferay, you have to apply your own coding logic since the implementation of FK are not available in service builder. So I guess you need to put some code.
Read some forums related to service builder on liferay website. It will give you better exposure.
Read Liferay In Action. It is a good book
Here is What I obeserved In Liferay 6.1.
com.liferay.portlet.p_name.model:
This has interfaces and classes related to (table entity related to) this portlet.
For example com.liferay.portlet.announcements.model will have
Interfaces:
AnnouncementsEntry
AnnouncementsEntryModel
AnnouncementsDelivery
AnnouncementsDeliveryModel
AnnouncementsFlag
AnnouncementsFlagModel
Classes:
And In classes section, You will find wrapper classes and soap classes for each entity like:
AnnouncementEntryWrapper
AnnouncementEntrySoap
AnnouncementFlagWrapper
AnnouncementFlagSoap
AnnouncementDeliveryWrapper
AnnouncementDeliverySoap
Also for few Entity, you will find Classes for Constant entries like
AnnouncementsEntryConstants, AnnouncementsFlagConstants etc.
com.liferay.portlet.p_name.service:
This has classes and interfaces related to (table entity related to) this portlet.
For example com.liferay.portlet.announcements.service will have
Interfaces:
AnnouncementsEntryService
AnnouncementsEntryLocalService
AnnouncementsDeliveryService
AnnouncementsDeliveryLocalService
AnnouncementsFlagService
AnnouncementsFlagLocalService
Classes:
And In classes section you will have Util and Wrapper classes.
AnnouncementsEntryServiceUtil
AnnouncementsEntryServiceWrapper
AnnouncementsEntryLocalServiceUtil
AnnouncementsEntryLocalServiceWrapper
and so on.....
So In short following is the structure I observed in Liferay
[In Model, I:+Model,(ModelName), C:Soap, Wrapper and Constants]
[In Service, I:Service,LocalService ; C:ServiceUtil,ServiceWrapper,LocalServiceUtil and LocalServiceWrapper]
[In Persistence, I:Finder(BlogsEntryFinder),Persistence(BlogsEntryPersistence); C:Util(BlogsEntryUtil, BlogsEntryFinderUtil)]
Note:
I --> Interface
C --> Class