►FR◄ 2 New Object Properties/Annotations

BenHayat

1) Unique Object - Instead of coding it in rule that has to do search every time a new object is being created, especially in loops with large number of records being created, it's best to check an object as Unique=true/false at the BO design time. This way, Aware can use the SQL engine to perform the uniqueness which is much faster, than doing search every time we're adding new object.
Many systems offer this as their basic DB management.

2) Composite index - Ability for us to select several attributes (in the correct order) at design time, to tell Aware to create a composite index for SQL engine to use. This helps hugely when trying to get to some records and you already have parts of the composite index, for example in multi tenant, this feature can help with performance greatly as data grows.
This is also another feature offered by many other products.

weblike

As I'm doing only multi tenants apps, I consider performance and optimization huge priority.
+10 for both proposals.

pureist

..and in the Config Tool on a Tab for an Object:

it should be possible to order the Attributes (via up and down arrows) so they can appear in a logical heirarchial order. This is possible now only by prefixing their names with a number or letter.

I reckon new users while learning would find this more intuitive.

as well as Name, Type, Initial Value, Choices, and Required, there should also be:
...a. Unique (or Distinct)
...b. Calculated
...c. Max. Length/Format/Multiple Allowed/Path (..ie. whichever is applicable to the Object Type

Again, this would make the learning process for new users more intuitive if they could see key settings for all Attributes of an Object at a glance, without having to double click on each attribute to open its settings dialog to double check everything.

RentProperty

+10
Some good ideas!! I'm sure support will consider. and tip of the cap for what they have now already done with the styles! Will save a lot of time.

Excited to see where this product will be in 2 years in terms of JSON service and the configurator.

BenHayat

One major part of the IDE that is very time consuming and confusing to get to, is that, there are way too many dialog boxes to go to, for properties. This is one area, that Aware needs a complete consolidation of these boxes to a single dialog box that we can get to. For example, for a form, a single dialog with all the properties in on dialog box open, perhaps with tabs inside, so we don't have to open/close so many times.

Here is a screen shot how VS offers properties for a form. they're all organized in one scroll able area and each has the ability to expand or collapse to save space.
I think this approach of having a properties area on the right side of Aware IDE that is always visible (could be hidden if needed to be) can save allot of time.

One other interesting feature with above dialog is that, depending what component you're working with on the form, the properties changes. For example, if I'm dealing with a button, the properties dynamically changes to following.

CalD

In regards to the composite index request, I don't think aware offers query hints to be passed to sql to force the index used for a specific query? 99.9% of the time you don't want this anyway the sql optimized does a fine job of choosing what index to use.
You can define composite index in sql direct and it will use it even if aware doesn't specifically know about it.
I'm building an app which is multi tenant but also inside each tenant is multi company, I am making many index with 3+ segments!

CalD

Also I agree the properties do need to be consolidate into 1 area with groups and made searchable etc

BLOMASKY

My 0.02 cents worth.

Composite indexes: As someone already stated, Aware does not send "hints" to the DB back end. I would much rather create my own indexes. There is a lot more to performance than just creating the index. Fill Factor, Physical table ordering are some factors than can have significant impact in not just retrieving records, but also when you are creating (inserting) new records. Each back end DB has its own features when creating these, and there is no reason for Aware to do this.

Uniqueness: As far as I know, a DB will only enforce uniqueness when you are either inserting a record (or changing an attribute) that "breaks" the unique rule. So you will only get a response when Aware attempts to commit your changes. I would much rather have a SP or an aware process that attempts to reach the unique attribute and if it finds a match, display an error when the user has entered / changed the field rather than wait for a failure when updating the table. Esp. if my update is part of a multiple table (errr, sorry BO) update.

Bruce