Code sample comments

Author: kushagraThapar

articles/cosmos-db/sql/migrate-containers-partitioned-to-nonpartitioned.md

@@ -133,10 +133,11 @@ static class Family {
 CosmosDatabase cosmosDatabase = cosmosClient.getDatabase("testdb");
 CosmosContainer cosmosContainer = cosmosDatabase.getContainer("testcontainer");
 
-
+//  Create single item
 Family family = new Family("id-1", "John", "Doe", "Doe");
 cosmosContainer.createItem(family, new PartitionKey(family._partitionKey), new CosmosItemRequestOptions());
 
+//  Create items through bulk operations
 family = new Family("id-2", "Jane", "Doe", "Doe");
 CosmosItemOperation createItemOperation = CosmosBulkOperations.getCreateItemOperation(family,
     new PartitionKey(family._partitionKey));
@@ -154,11 +155,14 @@ While the container definition is enhanced with a partition key property, the do
 Applications can access the existing documents that don’t have a partition key by using the special system property called "PartitionKey.None", this is the value of the non-migrated documents. You can use this property in all the CRUD and query operations. The following example shows a sample to read a single Document from the NonePartitionKey. 
 
 ```java
-CosmosItemResponse<JsonNode> cosmosItemResponse = cosmosContainer.readItem("itemId", PartitionKey.NONE, JsonNode.class);
+CosmosItemResponse<JsonNode> cosmosItemResponse = 
+  cosmosContainer.readItem("itemId", PartitionKey.NONE, JsonNode.class);
 ```
 
 For the complete sample on how to repartition the documents, see the [Java samples][2] GitHub repository.
 
+---
+
 ## Compatibility with SDKs
 
 Older version of Azure Cosmos DB SDKs such as V2.x.x and V1.x.x don’t support the system defined partition key property. So, when you read the container definition from an older SDK, it doesn’t contain any partition key definition and these containers will behave exactly as before. Applications that are built with the older version of SDKs continue to work with non-partitioned as is without any changes.