This logic has ambiguous results in the case where the user has more than one existing profile and at least two of those existing profiles reference different layout IDs, in that this logic will assign the newly created profile whichever of those layout IDs it happens across first.  This will happen to work in the existing-use-cases case where all these profiles point to the same layout ID anyway, but this seems a trip hazard for that future fateful day when someone tries to take advantage of each profile being able to point to its own layout ID, like the status quo code was a trip hazard for this fateful day when someone is serious about making not-starting-with-"default"-profile a reality.  So.  More comment  inline here? Detect the unexpected case where there exist multiple nonzero existing layout IDs amongst the existing profiles for this user and log this odd situation?  

Would also be cleaner to extract this logic for determining whether and what existing layout ID is value for a user given the user's existing profiles out into a helper method or even a separate utility rather than having it inline here.  As in, this would be cleaner as

    pstmt.setInt(8, layoutIdGivenProfiles(profile, profiles) );

with this `doInConnection()` able to confidently set prepared statement integer number 8 once rather than branch inline to figure out what to set it to.