Git : Best practices based on previous version control variants

In trying to get my head around the very different basis on which Git is built, I've identified the following sequence of steps in order to ensure logical interaction with Git (local and remote repository)

1. git add : Add or remove your changes to the current local index (local repository)
2. git stash : Move your local changes as committed to the local index to a local branch index and remove it from the current local index (This is necessary in order to pull the latest code changes from your Git remote repository...without maybe causing a merge push request)
3. git pull : Synchronise your local repository with the remote repository by pulling in the remote changes into your local index.
4. git stash pop : Restore your changes which have already been added to your local index. If you remember, you will know these changes have been moved from the local index to a local branch index. By executing "stash pop" your existing changes are moved back to the local main index. This might also cause you to have to merge your changes...depending on the state at which the remote repository was synched.
5. git commit -m "<commit message>" : Commit the changes you have made to your local Git repository with the given commit message.
6. git push : Commit the changes you've commit to your local repository, also now to your remote repository.

I hope you find it as helpful as I did. 

Deleting ".jdb" project files from your ADF project structure

When you are having referencing issues in JDeveloper which are not real since the references can be resolved. Try nuking the IDEs database files...after closing JDeveloper...then start it up again and the referencing issue will be something of the past. Unless, it was a real compilation issue, things will return back tot normal.

Here's the command you can use: del /S /Q *.jdb

View Object Bind Parameter pitfall

Well one get to a point in ADF development when it has been a long time since you've referenced the ADF Documentation and so I got to this pitfall with regards to Bind Parameters on View Objects. In my specific scenario I wanted to use Bind Parameters with wildcard values such as nulls amongst others. Hence, I discovered out of my ignorance that Bind Parameters get excluded when they have null values, unless they are marked as required parameters. After hours of debugging and struggle to get things working, everything started working suddenly after making all bind parameters required.

One of my colleagues also discovered another rule (as documented) with regards to view objects and bind parameters, but I'll provide those hints at another time...

Here it is:
Bind parameters marked as required can only be used in your main VO query. Those not marked as required can only be used in your View Criteria.
Thanks to Anilin Reddy!!

Oracle ADF : How to change an attribute value of the read-only iterator's current row

// change attribute value of current row in iterator

DCIteratorBinding iterBind = ADFUtils.findIterator("MyVOIterator");
Row currRow = iterBind.getCurrentRow();
BackingBeanUtils.setRowEditable(currRow);
currRow.setAttribute("MyAttribute", "MY_VALUE");

// commit transaction
iterBind.getDataControl().commitTransaction();

...and for reference purposes, the setRowEditable(Row) utility method:

public static void setRowEditable(Row row) {
    int attribCount = row.getAttributeCount();
    for(int i = 0; i < attribCount; i++) {
      ViewAttributeDefImpl attrDef = (ViewAttributeDefImpl)

              row.getStructureDef().getAttributeDef(i);
      attrDef.setEditable(true);
      attrDef.setSDOHidden(false);
      attrDef.setUpdateableFlag(ViewAttributeDefImpl.UPDATEABLE);
    } 

}