My passbooks are user's store cards, they have same certificate (same pass type identification) and category as discuss in this link, but I don't want them to group together since they are for many different stores or business. Any way to do that.
For storecard passes, the only way to prevent grouping is to use a different certificate. coupon, storecard and generic passes with the same passTypeIdentifier will always be grouped together.
For eventTicket and boardingPass types, you can use a groupingIdentifier key to separate passes with the same passTypeIdentifier into different groups.
groupingIdentifier |
string |
Optional for event tickets and boarding passes; otherwise not allowed. Identifier used to group related passes. If a grouping identifier is specified, passes with the same style, pass type identifier, and grouping identifier are displayed as a group. Otherwise, passes are grouped automatically.
Use this to group passes that are tightly related, such as the boarding passes for different connections of the same trip.
Available in iOS 7.0.
PassKit Package Format Reference
Related
I have two subscriptions on the same record type List: the first one for the creation of records of type List with a reference to a record A and the second one for the creation of records of type List with a reference to a record B.
I'm using silent notifications with CKFetchNotificationChangesOperation to don't miss an update. The main problem is how to use CKServerChangeToken: should I use two tokens depending on the subscription or is using just one token for all the subscriptions on a record type (in that case List) working?
I want to make a database for an iOS application consisting of groups that can have the same name. I am hosting my database on AWSDynamo.
Since multiple groups can have the same name, I was planning on having a groupID as the hashkey, unless someone can suggest a better method.
My main problem is storing an integer that will be the number of groups. This is so that when a user creates a new group the number will be incremented and the new group will get that number as its groupID.
How can I store an integer in such a fashion that all users can access it from the app?
UUID – Universally unique identifier
You can use a UUID (String) as your groupID in your groups table, and use conditional writes (PutItem, UpdateItem) to handle the extremely rare case where there is a collision. If you create a UUID for a new group where the UUID already is assigned to another group, you will get a ConditionalCheckFailedException so you can retry with a new UUID. You don't need to use an incrementing sequence to uniquely identify groups.
I'm building a Ruby on Rails App for a business and will be utilizing an ActiveRecord database. My question really has to do with Database Architecture and really the best way I should organize all the different tables and models within my app. So the App I'm building is going to have a database of orders for an ECommerce Business that sells products through 2 different channels, a subscription service where they pick the products and sell it for a fixed monthly fee and a traditional ECommerce channel, where customers pay for their products directly. So essentially while all of these would be classified as the Order model, there are two types of Orders: Subscription Order and Regular Order.
So initially I thought I would classify all this activity in my Orders Table and include a field 'Type' that would indicate whether it is a subscription order or a regular order. My issue is that there are a bunch of fields that I would need that would be specific to each type. For instance, transaction_id, batch_id and sub_id are all fields that would only be present if that order type was a subscription, and conversely would be absent if the order type was regular.
My question is, would it be in my best interest to just create two separate tables, one for subscription orders and one for regular orders? Or is there a way that fields could only appear conditional on what the Type field is? I would hate to see so many Nil values, for instance, if the order type was a regular order.
Sorry this question isn't as technical as it is just pertaining to best practice and organization.
Thanks,
Sunny
What you've described is a pattern called Single Table Inheritance — aka, having one table store data for different types of objects with different behavior.
Generally, people will tell you not to do it, since it leads to a lot of empty fields in your database which will hurt performance long term. It also just looks gross.
You should probably instead store the data in separate tables. If you want to get fancy, you can try to implement Class Table Inheritance, in which there are actually separate but connected table for each of the child classes. This isn't supported natively by ActiveRecord. This gem and this gem might be able to help you, but I've never used either, so I can't give you a firm recommendation.
I would keep all of my orders in one table. You could create a second table for "subscription order information" that would only contain the columns transaction_id, batch_id and sub_id as well as a primary key to link it back to the main orders table. You would still want to include an order type column in the main database though to make it a little easier when debugging.
Assuming you're using Postgres, I might lean towards an Hstore for that.
Some reading:
http://www.devmynd.com/blog/2013-3-single-table-inheritance-hstore-lovely-combination
https://github.com/devmynd/hstore_accessor
Make an integer column called order_type.
In the model do:
SUBSCRIPTION = 0
ONLINE = 1
...
It'll query better than strings and whenever you want to call one you do Order:SUBSCRIPTION.
Make two+ other tables with a foreign key equal to whatever the ID of the corresponding row in orders.
Now you can keep all shared data in the orders table, for easy querying, and all unique data in the other tables so you don't have bloated models.
Im designing an application which manages the renting of lots of different equipment. And I am wondering whats the best way to design the models for the application. My software has to manage lots of different types of equipment (with data types) for example:
Speaker
Make - String
Model - String
Wattage - Integer
Price - Decimal
Light
Make - String
Model - String
Wattage - Integer
Price - Decimal
Microphone
Make - String
Model - String
Use - Choice of: Instrumental, Vocal, Versatile
Price - Decimal
Cable
Length - Decimal
Connector 1 - String
Connector 2 - String
Price - Decimal
Stand
Type - Choice of: Microphone, Speaker
Height - Decimal
Boom - Boolean
Price - Decimal
Ways I have thought about the design:
An individual model for each type of product then a polymorphic association in the cart so that it can handle all the types of equipment.
A single product model that has fields for all types of equipment with a type field which can be checked when ever the product is used.
A product model with a price attribute then every type of product extends that model.
But what is the best way in rails to handle these different types of products?
The Dynamic Attributes gem should allow you to do this automatically:
https://github.com/moiristo/dynamic_attributes
There may be better gems that do what you need, but this is the first I found.
If you're using Postgres as your database, then you can use hstore. There are gems to work with hstore. If you can afford, get a subscription to railscast and watch the screencast about implementing hstore.
Activerecord-postgres-hstore seems to be the go to gem for this.
I'd personally go with a single model Product and another model called ProductAttribute.
In this table, you'd have a name column and a value column.
This way, you're not limited by your schema. A product has n product_attributes, named dynamically. You can in the admin section develop shortcuts so if you create a microphone product, it'll automatically create the specific attributes names in the linked table. You'd just have to input the values.
This way, your application is fully able to sell any sort of produts with any amount of attributes. No need to code again when in 3 months the manager will want to add another type of product :)
Edit : And of course, you'd have a ProductType model to manage all the different product types you can sell.
Another option would be to make a product attributes table, and build each product type over an admin interface instead of in low-level code. That way you would not need to alter te application to sell new products.
This is a problem that has caused headaches to many vendors of ERP solutions before.
The most elegant solution I would suggest to you based on what I've seen at one such vendor is this.
You define 4 models:
Equipment, EquipmentType, Characteristic, Choice.
There would be a many-to-many relationship between Equipment and Characteristic, going through EquipmentType.
The Characteristic model has an attribute called "value_type" and also one attribute for each value type you have (String, Integer, Decimal, Boolean).
Finally, there would be a one-to-many relationship between Characteristic and Choice.
This is actually a watered-down version of that vendor's implementation which is suited to your particular requirements.
That vendor's actual implementation is actually built at one or two levels of abstraction above what I'm showing you, in order to make the solution more generic. But those people are well-known for over-engineering things.
HTH.
The third approach is pretty close the right one. You will definitely want to abstract out all of the universal parameters for the items (such as store ID, and, as you mentioned, price) into the base model that every other item will extend. Then, as you mentioned in your first proposed solution, you will have references between the rest of the item classes where necessary, using :references.
As for the "type" and "use", you will probably be best off using a one to one relationship with the parent model. Then, store a list of possible field types for each of the models (for example, for Stand, something like possible_uses = "Microphone, Speaker"). Finally, do server-side validation when the model is instantiated that ensures that it's of a valid type. You can also do some hacks that will allow you to see make sure that Microphone and Speaker are the only two possible "uses" that your code actually uses.
A completely different, but cleaner way to do this would be to do everything I mentioned in the first paragraph, but continue the inheritance down to the lower levels. Specifically, have Microphone extend BaseItem, give Microphone the Make and Model parameters, and then have models InstrumentalMicrophone, VocalMicrophone, andVersatileMicrophoneextend theMicrophone` class. This will be the cleanest and will allow for full functionality.
I am making a Ruby on Rails app and am realizing that my User class could potentially end up with a lot of generic boolean / integer attributes. For example, suppose I have a promotion each quarter, and I only want a person to be able to use the promotion once. Then I'd have to make a new column each quarter has_used_promotion_N to track that promotion.
Alternatively, I'm thinking of creating a new column called "Generic Flags" which is just a comma separated value of flags set on the account. For example:
"has_used_promotion_1, has_used_promotion_2, limit_on_feature_a=20" etc. could be set for some particular user
(or maybe I'll store it as JSON)
In any case, I'm thinking of giving myself some sort of NoSQL-like functionality in my DB.
Is this really bad design for some reason? Has anyone else done this before? Anything I'm completely missing about RoR?
In my opinion Promotion should be a separate model with a many to many relationship with User. When you have a promotion you would create a Promotion instance and when a person uses that promotion you add that person to promotion.users relationship.
This is much better than your idea because you can now query those relationship. Want a list of all users that used the first quarter promotion? No problem. You can do that with your solution, but you have to resort to some hackiness (is that a word?) to do it, and you'd have to parse the generic flag string for EVERY user on EVERY query. Not ideal to say the least.
If there's an arbitrarily-sized collection of associations then it should be a real relation, modeled using the existing DB and facilities. Promotions sounds like that, and it seems like it would be something you'd be modeling in your DB already; no real reason to keep a duplicate value hierarchy.
For actually-generic flags, you could have a named-flag table and again use a real association.
You could also just serialize a flag object to a text column. Doing so impedes your ability to do trivial searches on a flag/flag value, however. This may not matter for a wad of flags associated with a single user that you don't care about unless they're logged in, but tread lightly--it depends on your usecase.