I have a simpledb column 'Status' I want to get rid of it. How can I delete it ? I dont see any intuitive way to do so.
Thanks
Since SimpleDB is a schema-less database each item may have different sets of attributes. In order to remove a particular attribute from all items you're going to need the itemNames for all items containing the attribute.
If you've decided to emulate a relational table in SimpleDB (by having one domain per 'table' and uniform attributes per item) you can retrieve all itemNames by a simple select query select itemName from domainX.
Once you've got the itemNames for the items which contain your unwanted attribute you'll need to call DeleteAttributes once for each item.
Related
We have two teams working on system related issues and my Access database has one table for each teams open issues. I have created a query that matches issues from each list based on the system name. The query is returning potential matches correctly.
From there, I need to be able to review each "match" and select yes or no on a dropdown to confirm if both teams are working the same issue in order to quickly and easily reduce redundancies. I would prefer to review each result in a form format and have figured out how to add a dropdown box with the yes/no options; however, once I've validated each item, I'd like to filter the results down to only show the items that have been designated as "yes".
That's where I'm stuck. The form is not currently saving the results, including the dropdown info, to a table from what I can see.
How can I get the form to load to a table (or query) in order to filter out the "no" responses?
Try converting your query to an append query or an update query. Create a new table that this query adds data to, and in that table create a new field called "YesNo" or something like that. Put that new field from your table as a control source for your dropdown and should add a value in the "YesNo" field in your new table based on what you select. I'm not sure what value will be added to the table, I did something similar with a check box, when it's clicked it adds a "-1" and when it's unclicked, it adds a 0. Then I run a report that selects records based on the value in that field. I'm assuming the dropdown would work in a similar way but not a 100% sure. Hope I understood your issue, I'm no expert at access but I ran into the opposite issue recently where I didn't want the form to save the results.
I have been using different methods to get specific fields from active record, But which one is faster and preferred to use and how are they different from one another?
User.all.collect(&:name)
User.all.pluck(:name)
User.all.select(:name)
User.all.map(&:name)
Thanks for your help in advance.
Usage of any of these methods requires different use cases:
Both select and pluck make SQL's SELECT of specified columns (SELECT "users"."name" FROM "users"). Hence, if you don't have users already fetched and not going to, these methods will be more performant than map/collect.
The difference between select and pluck:
Performance: negligible when using on a reasonable number of records
Usage: select returns the list of models with the column specified, pluck returns the list of values of the column specified. Thus, again, the choice depends on the use case.
collect/map methods are actually aliases, so there's no difference between them. But to iterate over models they fetch the whole model (not the specific column), they make SELECT "users".* FROM "users" request, convert the relation to an array and map over it.
This might be useful, when the relation has already been fetched. If so, it won't make additional requests, what may end up more performant than using pluck or select. But, again, must be measured for a specific use case.
pluck: retrieve just names from users, put them in an array as strings (in this case) and give it to you.
select: retrieve all the users from db with just the 'name' column and returns a relation.
collect/map (alias): retrieve all the users from db with all columns, put them in an array of User objects with all the fields, then transform every object in just the name and give this names array to you.
I put this in order of performance to me.
I'm looking to speed up queries to my SQL backed CoreData instance (displaying records sorted by date). I know that indexing can help decrease query time, but what's the difference between:
Highlighting the entity that an attribute belongs to, then adding a comma separated list of attributes into the indexes field as seen here:
Or highlighting the attribute, then checking the indexed box as seen here:
Adding a row with a single attribute to the Indexes list is equivalent to selecting Indexed for that attribute: It creates an index for the attribute to speed up searches in query statements.
The Indexes list is meant for compound indexes. Compound indexes are useful when you know that you will be searching for values of these attributes combined in the WHERE clause of a query:
SELECT * FROM customer WHERE surname = "Doe" AND firstname = "Joe";
This statement could make use of a compound index surname, firstname. That index would also be useful if you just search for surname, but not if you only search for firstname. Think of the index as if it were a phone book: It is sorted by surname first, then by first name. So the order of attributes is important.
In your case you should go for the single indexes first (that is, select Indexed for the attributes you like to search for). The compound index you showed could never be used if you just search for babyId, for example.
At WWDC 2017, apple updated this to instead be done by using a Fetch Index(see: https://developer.apple.com/videos/play/wwdc2017/210/?time=997)
To add it, select the entity and then go to Editor -> Add Fetch Index
In Xcode you can add "Indexes" for an entity in the data model inspector.
For the screenshot I did hit "add" twice so "comma,separated,properties" is just the default value.
What exactly are those indexes?
Do they have anything to do with indexed attributes? And if they have what is the difference between specifying the Indexes in this inspector and selecting "Indexed" for the individual attribute?
Optimizing Core Data searches and sorts
As the title says, indexing is to speed up searching and sorting your database. However it slows down saving changes to persistant store. It matters when you are using NSPredicate and NSSortDescriptor objects within your query.
Let's say you have two entities: PBOUser and PBOLocation (many to many). You can see its properties at the image below:
Suppose that in database there is 10,000 users, and 50,000 locations. Now we need to find every user with email starting on a. If we provide such query without indexing, Core Data must check every record (basically 10,000).
But what if it is indexed (in other words sorted by email descending)? --> Then Core Data checks only those records started with a. If Core Data reaches b then it will stop searching because it is obvious that there are no more records whose email starts with a since it is indexed.
How to enable indexing on a Core Data model from within Xcode:
or:
Hopefully they are equivalent:-)
But what if you wanted: Emails started with a and name starts with b You can do this checking INDEXED for name property for PBOUser entity, or:
This is how you can optimise your database:-)
Use the Indexes list to add compound indexes to the entity. A compound index is an index that spans multiple attributes or relationships. A compound index can make searching faster. The names of attributes and relationships in your data model are the most common indexes. You must use the SQLite store to use compound indexes.
Adding a row with a single attribute to the Indexes list is equivalent to selecting Indexed for that attribute: It creates an index for the attribute to speed up searches in query statements.
The Indexes list is meant for compound indexes. Compound indexes are useful when you know that you will be searching for values of these attributes combined in the WHERE clause of a query:
SELECT * FROM customer WHERE surname = "Doe" AND firstname = "Joe";
This statement could make use of a compound index surname, firstname. That index would also be useful if you just search for surname, but not if you only search for firstname. Think of the index as if it were a phone book: It is sorted by surname first, then by first name. So the order of attributes is important.
I have a DBGrid with a column based on a lookup field.
How can I set it up so that when a user clicks on the column title, it will sort by that field.
My problem here is that I can't figure out a way to create an index on a lookup field.
I'm using Absolute Database for this, but most things that work with the BDE or TClientDataSet will work with Absolute.
Thanks!
I don't think it is possible to create an index on a lookup field. It is possible to create an index on an internally calculated field of a ClientDataSet though. In the OnCalcFields event handler set its value to the value of the lookup field. And set the visible property of the lookup field to false. Now you can sort on the internally calculated field.
What you could do (especially if the data is readonly, and does not have zillions of rows) is use a ClientDataSet to display data in your grid.
Roughly the steps would be like this:
Load the data from your regular into the ClientDataSet,
add a calculated field to the ClientDataSet that contains the value obtained from the lookup,
then add an index to that calculated
field.
--jeroen
You cannot sort by a lookup field. But you can 'fake' this. Let's suppose that you have the following tables: (PK means Primary Key)
Contacts
ID - Integer (PK)
NAME - Varchar(40)
COUNTRYID - Integer
Countries
ID - Integer (PK)
NAME - Varchar(40)
Then you can have the following query in the dataset which is linked to the TDBGrid:
SELECT C.ID, C.NAME, C.COUNTRYID, CO.NAME
FROM CONTACTS C
JOIN COUNTRIES CO ON C.COUNTRYID=CO.ID
(Not tested but I think that you got the idea)
Also you can put this in a view.
Then you'll display in your TDBGrid (as columns) only the ID, NAME and the desired lookup field which you already have (let's call it COUNTRYLOOK).
When one clicks on the Title Header you can change the query by adding in the 4th line an ORDER BY . For the specific column of the lookup field (COUNTRYLOOK), instead of using the 1:1 mapping you can put in the 4th line of your query ORDER BY CO.NAME. Reopen the query and that's it. In practice is much more simpler than my description here.
DevExpress ExpressQuantumGrid can do it, check it out:
http://www.devexpress.com/products/vcl/exquantumgrid/