I would like to store PHAsset.localIdentifier in my database. Syncing this does not make sense since each device will have different identifier for given photo. Can I somehow configure Ensambles to ignore one property when syncing?
You can add CDEIgnoredKey to the property in the user info of the model, with a value 1, and Ensembles will not sync the property.
Related
I note that the following code...
JsonbBuilder.create( new JsonbConfig()
.withPropertyVisibilityStrategy( mRoleBasedPropertyVisibilityStrategy )
...creates a Jsonb instance whose PropertyVisibilityStrategy only gets called once per class. Subsequent calls appear to cache the visibility of each property.
This makes it inappropriate for something like a mRoleBasedPropertyVisibilityStrategy, which needs to check the visibility each time based on a given logged-in user's role.
Is there a way to force PropertyVisibilityStrategy not to cache?
Trying to save an h2o model with some specific name that differs from the model's model_id field, but trying something like...
h2o.save_model(model=model,
path='/some/path/then/filename',
force=False)
just creates a dir/file structure like
some
|__path
|__then
|__filename
|__<model_id>
as opposed to
some
|__path
|__then
|__filename
Is this possible to do from the save_model method?
I can't / hesitate to simply change the model_id before calling the save method because the model names have timestamps appended to them to avoid name collisions with other models that may be on the h2o cluster (am trying to remove these timestamps when saving on disk and simplifying the name on the cluster before saving creates a time where naming collision can occur if other processes are also attempting to save such a model (of, say, a different timestamp)).
Any way to get this behavior or other common alternatives / workarounds?
This is currently not possible, however I created a feature request here. There is a related question here which shows a solution for R (could be adapted to Python). The work-around is just to rename the file manually using a few lines of R/Python code.
I'm currently building a Laravel 5.7 app where I have multiple boolean columns that indicate if some facilities are available for a building (model), eg, toilet yes/no. This works fine, but I was wondering what happens when I add more of these boolean columns later when I deploy the app.
Say I add a boolean column 'lights,' I could give it a default value of 0, but not NULL. So now all my existing buildings will say that there are no 'lights' (because the value is 0), where in reality it should be something like 'don't know' or 'undefined' Like a third state.
Should I use ENUM columns with yes/no/undefined instead? What are best practices for this scenario?
What I would do, is create separate table, with object_id, and facility_id. Now, you can have dynamic facilites table, and connect them with object. Connection will only have what it needs, so not every object "light" or something else.
You can certainly create them them as nullable()! It is a common practice, IMO.
As far as best practices go, it depends on how your application should be used. Do you want a user to notice that the state has not been selected one way or the other yet? Maybe you are displaying a prompt to configure the ones that are null. On the other hand, it may be safer to assume that the options should default to false in order to be rendered properly. If this is the case, maybe a notification can go out to your users to update this property.
This worked to me
$table->boolean('lights')->nullable();
Yes Yo are Right this could be a problem some times
But the Boolean CAN BE USED SUCH AS TRUE (OR) FALSE ie) 0 (OR) 1
where in reality it should be something like 'don't know' or 'undefined' Like a third state.
So in this Situation use Can use Enum
For Example Your table will have ups_availablity
Scenario One :
If you want to add NotAvailable by default just pass the value inside default method
$table->enum('ups_availablity', ['Available', 'NotAvailable'])->default('NotAvailable');
Scenario Two:
If you want to add Null add nullable method
$table->enum('ups_availablity', ['Available', 'NotAvailable'])->nullable();
If You have any clarification Kindly Comment Below
Hope its helps
I need to retrieve a list of Active Directory users and their attributes using Delphi 2010.
I've seen a few similar questions on SO (e.g. Delphi - Find primary email address for an Active Directory user), but they all seem to require the user name before any additional information can be retrieved.
I had written an article for [The Delphi Magazine] way back when..... if you have access to a backlog of those magazines, it's in issue no. 62 (October 2000) - unfortunately, it seems those back issues aren't available for purchase anymore :-(
It's too long of an article and a code sample to post here.... basically it's about wrapping the IDirectorySearch interface in a nicer Delphi-like shell. You pass in a base container where to search, you define an LDAP filter, and you define a set of attributes you're interested in - then you search and get back basically an enumerator for the results, which you can get one by one.
In the end, I discovered TJvObjectPickerDialog, part of JVCL. It wraps the Windows Select Object dialog and does everything I need with very little coding. Just set the required properties and call execute. The selected user objects are returned along with the attributes that you set in the 'Attributes' property.
I need to reference ABPerson records from within an application. I use the unique ID provided by
- (NSString *)uniqueId
and attach it to my in-app contact record.
Additionally, I save ABPerson's vCardRepresentation as a fallback. In case the app isn't any longer able to locate the ABRecord using the uniqueID, the app asks the user to recover the adressbook record using the saved vCardRepresentation. All works fine.
Unfortunately, a friend told me, that uniqueId isn't immutable: During a sync, uniqueId may suddenly change.
According to him, somewhere in iOS documentation, Apple explains that no way exists to immutable identify ABPersons using uniqueId. In OS X' Cocoa documentation, I failed to find such a hint.
On a given Mac, may the uniqueId change suddenly? If that's true, what's the correct way to identify ABPerson records from within an external application?
In case the uniqueID isn't immutable, I certainly may assign a custom property with a GUID. Unfortunately, custom fields do not sync.
Certainly, I'd prefer to use uniqueId.
For whats its worth, from Apple's techdoc:
kABUIDProperty
The unique ID for this record. It’s guaranteed never to change, no matter how much the record changes. If you need to store a reference to a record, use this value. Type: kABStringProperty.
Available in Mac OS X v10.2 and later.
Declared in ABGlobals.h.
It looks like the kABUIDProperty approach might not work anymore. I came across this blog entry with more discussion in the comments at: http://blog.clickablebliss.com/2011/11/07/addressbook-record-identifiers-on-mac-and-ios/.
A case in point: If a user decides to turn on iCloud sync, the unique ids in that user's address book will change. If the users turns off iCloud sync, they'll change again.
Addendum: it might be worthwhile looking at the StackOverflow entry here.
Apple's docs do say this (quoted from the link):
"The recommended way to keep a long-term reference to a particular record is to store the
first and last name, or a hash of the first and last name, in addition to the identifier.
When you look up a record by ID, compare the record’s name to your stored name. If they don’t match, use the stored name to find the record, and store the new ID for the record."