I'm investigating the way to add a iCloud-sync functionality to a NSPersistentDocument based app.
Could I use NSPersistentCloudKitContainer and use a different CKRecordZone for each document?
Each document would then sync to iCloud.
Note that using NSPersistentCloudKitContainer is a requirement.
Related
Is there a good practice to introduce existing legacy database tables/entities into a JHipster project?
The idea I had was to create the JPA entities that look exactly like the existing entities and then use the generated artifacts as per normal. Will this possibly work?
In the end, I opted for just creating a view of all the underlying tables I needed in my query. The steps I followed were:
create the view on the DB,
Generate the entity using JHipster, with exactly the same fields.
Strip out the Update ad Create and Delete functions and we have a read-only view page with all the data you need and all the fields displaying, done.
Now I can add my own routers and buttons, to allow other specific operations/flow. This page was my inspiration: https://www.javabullets.com/calling-database-views-from-spring-data-jpa/
I have a project entity and a projectStages entity. I want, when a project record will be created automatically projectStages entities will be created for each stages.Till now I was doing it using plugin.
Just wanted to know if there is any way I within the CRM to do this.
this is a screen shot of the customer security roll.
Thanks.
I would do that using plugins, is there any reason you don't want to use plugins? You could use workflows to create projectstages when a project is created too, that will be asynchronous though.
I don't know about SharePoint that much, so hope that someone can give me some good explanations for me.
For SharePoint application, we don't need to consider SharePoint DB design? Everything is done through List and SharePoint will take care of the Database? Don't need to consider it at all unless we are connecting to the external Database?
For Parent Child relationship, I have to use lookup field?
If we are developing using Web parts, we need to deploy it using Features. So eventually, there can be so many features in the production? Is it recommended in this way?
1)
For SharePoint application, we don't need to consider SharePoint DB
design ? Everything is done through List and SharePoint will take care
of the Database ? Don't need to consider it at all unless we are
connecting to the external Database ?
You do need to consider the database... In term of administration. back ups, restore, size and so on.
however you never directly read or write to it. You don't need to pay attention to the schema because you won't ever be directly using it. If you want to update something in SharePoint you do it pragmatically with c# / vb.net using the SharePoint API's. You have 2 API's one that works on the server called the SharePoint object model and one that works on a remote machine called the client side object model.
From a users perspective, you are correct lists contain data in SharePoint and are somewhat smiler to DB tables in some ways.
2)
For Parent Child relationship, I have to use lookup field ?
Yip
3)
If we are developing using Web parts, we need to deploy it using
Features. So eventually, there can be so many features in the
production ? Is it recommended in this way?
This can happen if you create a new solution for every web part but you can bundle multiple web parts in the same solution in the same project in the same feature
Right click on your project --> add new item. select a web part. By default the web parts will all be part of the same feature but you can separate them out and have multiple features in the same solution if you want to
What is the difference between this services?
DLFileEntryLocalServiceUtil
and
DLAppLocalServiceUtil
When should we use one and when the other? Is DLAppLocal a new interface in Liferay 6.1 which discourages the old DLFileEntry for application level code?
What is the difference between these services DLFileEntryLocalServiceUtil and DLAppLocalServiceUtil?
DLFileEntry services and DLFolderEntry services are specifically for storing file and folder entries in liferay's database and are totally unaware of the new repository concept introduced in 6.1. The user-guide & this wiki explains how to add a new repository.
Were as DLApp (DLAppService & DLAppLocalService) services take into account these things i.e. to say that they take care of syncing documents between liferay database and other repositories, and not just store entries in Liferay database.
The documentation for the class DLAppServiceImpl explains it all (this is almost same for DLAppLocalServiceImpl), the following is an excerpt from the documentation:
The document library local service. All portlets should interact with the document library through this class or through DLAppServiceImpl, rather than through the individual document library service classes.
This class provides a unified interface to all Liferay and third party repositories. While the method signatures are universal for all repositories. Additional implementation-specific parameters may be specified in the serviceContext.
The repositoryId parameter used by most of the methods is the primary key of the specific repository. If the repository is a default Liferay repository, the repositoryId is the groupId or scopeGroupId. Otherwise, the repositoryId will correspond to values obtained from RepositoryLocalServiceUtil.
Is DLAppLocal a new interface in Liferay 6.1?
Yes
which discourages the old DLFileEntry for application level code?
In a sense yes, refer the above explanation. DlAppLocalServices is much better to use as its scope is much greater than the individual document services. Still if you want to use these interfaces for storing the documents & media from your custom plugin portlet you can go ahead and use these, I don't think there should be a problem since even DlAppLocalServices also internally uses the individual document services for storing in liferay repository.
Hope this provides some relevant information for your question.
I have created application with corde data model to populate my sqlite database with data. What I want to put this populated database to iphone application. In iphone application project I have added the sqlite database file that I had populated and have imported the mangedobjectmodel from my destktop application, but when I run the iphone application I get an error : reason = "The model used to open the store is incompatible with the one used to create the store";
Is it possible to use one managedobjectmodel in different applications, or I have to migrate the data from one managedobjectmodel to another.
Thank you for your help.
The exact model used to create the store must be available to the app. The model provides the only information that the Core Data stacks has to interpret the store as objects.
You must move the model from the MacOS app to the iOS app. If you need to change the model, you need to create a new version of the old model and then migrate the store from the old to the new.
This is actually easy to do. I quite often create models and pre-populated SQLite stores on my development Mac and then insert the results into an iOS app. Unless your making any changes as above, the process is seamless and no more difficult than importing the files into the project.