Designer bugs and general feedback

Hello,

I have some Issues and feedback regarding LightSpeed and the Model Designer.  I will begin with the issues.  I use a SQL 2005 database. I am using the May 20th nightly build.  All issues can be worked around.

Issue 1:

When dragging a stored proc over from the solution explorer, the designer doesn't always generate an entity for the output of the stored proc.  I have an entity that has no properties - or rather is a table with 1 PK, 2 FK's and no other columns. When I drag a stored procedure over the designer incorrectly assigns the output of the stored proc as the above mentioned entity, even though the stored proc does have output columns including an Id field.  If I remove said entity from the model, then drag the stored proc onto the designer, it correctly generates an output entity and assigns the output type as the new entity it has just generated.

If I add a property to the entity mentioned above, the designer then correctly generates an output entity for the stored proc.

While the designer appears smart enough to reuse the entity generated for the stored proc for more than one stored proc (as they have the same output) it is unfortunate this is happening.  I am happy to reproduce this for you in person.

Issue 2:

Stored procs that do not return a result set are not supported. Why not?  My solution is to select back the updated row, which is fine.

 Issue 3:

When looking at the properties for an association, the documentation for Backreference, Collection aggregates and eager loading is out of date.  Therefore, it is a guess as to which thing I am wanting to eager load.

Issue 4:

When right clicking an entity and going to "update database" it keeps trying to add an FK column to my entity. If you let it, an error is (correctly) spat out saying the column already exists.

Issue 5:

When right clicking an entity and going to "update from source" it keeps asking to delete an association.  If you right click the design surface (background) and go to "update from source" it doesnt ask to delete the association (and asks if you want to add it back if you accidentally deleted it, which is handy).

Issue 6:

When you have a stored proc output entity, if you right click the design surface and go to "update from source", it asks if you want to delete the special entity made for the stored proc output. I suggest you somehow mark this entity as something that shouldn't be deleted.

Issue 7:

Not that I do this all that often, but when I add an entity property that is not null, there is no way to set the default value in the designer.  If you add a property, I might want to set a default value.  Good that the designer correctly applies the default instantiated value of that data type if there are rows in the DB already.

And now for some general feedback:

Feedback 1:

It would be good to separate out sets of entities in the model, as my model is getting rather large now and I have to move things into their own corner.  A tab like way of organising various entities would make things a lot easier to manage. This might be a good way to help avoid Issue 6.  Putting stored proc stuff on its own tab, then only updating entities/database on the current tab would make things slightly easier to manage.

A zoom function on the model might also be cool, and if you hold your mouse over a miniscule entity it pops up tooltip style with the entity name.

Feedback 2:

For the dumbasses that don't put a starting int value into the keytable table, please put 1 in if there is no row with a number in it by default, and increment from there.

Feedback 3:

When dropping tables on to the design surface, if you have two FK columns pointing to the PK in a common table, the designer generates a name that is the same.  Adding an increment to this might be a good idea if the relationship label already exists. 

Feedback 4:

Keep up the great work.

Feedback 5:

Get rid of this shitty CS editor.

Feedback 6:

Please create custom collections for the results of a Find() query that implement INotifyCollectionChanged. Alternatively, tell me to use something that I have missed.

Bert.
End of line.

Thanks for the extensive feedback -- appreciate you taking the time to write it all up!

Issue 1.  We're open to suggestions as to what would be more helpful behaviour here.  One obvious option is for a sproc always to generate a new result entity type, which you can then delete if you don't want it.  But this is annoying if you have multiple queries as sprocs which all return the same type but with different criteria.  We could try matching sproc result schemas only to other sproc result entities, i.e. excluding table- and view-backed entities from the "look for an existing suitable result type" search, but this is unhelpful if sprocs represent "quick queries" for entities which are nevertheless table-backed e.g. for storage.  We could get fancy and start trying to use heuristics on the sproc name to see if it mentions an existing entity type, but that is potentially complex and of doubtful reliability.  What would your desired behaviour be?

Issue 2.  Scalar procedures are supported in the runtime using the Calculate(ProcedureQuery) method, but we haven't yet got round to them in the designer.  There's no deep reason, just a matter of prioritisation.

Issue 3.  Are you referring to the help file or to the description shown in the designer property grid?  If the latter then it should be showing something like "Indicates whether the backreference should be eager loaded (sets the EagerLoadAttribute on the EntityHolder in the generated code)," which seems reasonably explicit about which thing will be eager loaded -- but perhaps I'm too close to the problem.  I'd be pleased to improve the naming and description if you could suggest something or say a bit more about why it's confusing.

Issues 4 and 5.  These sound like the same issues in opposite directions, and are probably due to a bug in checking associated entities which might be inducing FKs on the selected entity.  I thought we had fixed this but evidently there's a case which has slipped through.  Could you send me your model and your database schema (CREATE TABLE scripts), and let me know which entity to right-click to repro the issue?  Thanks!

Issue 6.  Select the sproc result entity and change the Access Method to SelectProcedure.  This will exclude the entity from synchronisation.  You should need to do this only for existing sproc result entities; entities created from sprocs using the current version of the designer should have this property set automatically.  Let me know if this isn't happening for you.

Issue 7.  We'll take a look at adding this feature.

Feedback 1.  We definitely recognise this issue!  Unfortunately the toolkit we are using the build the designer makes the multiple views approach a bit difficult but we are continuing to think about this and we have recently added some incremental improvements around filtering and navigation: see http://www.mindscape.co.nz/blog/index.php/2009/05/11/navigating-around-models-in-the-lightspeed-designer/.  I realise these don't solve the problem but hopefully they will help a bit.  The 21 May nightly also adds a zoom box on the Model Explorer (but as noted on the blog you can already zoom using Ctrl+mouse wheel).  Tooltips when zoomed out is a nice idea -- thanks!

Feedback 2.  Noted.  We do provide a CREATE TABLE script which initialises the value as you suggest, but if you create the key table by hand then I realise this is easy to forget!

Feedback 3.  This behaviour is by design.  Suppose that we used the incrementing name (as the LINQ to SQL designer does), so we generated properties on a User class called (say) Comments and Comments1.  The developer merrily develops away, using the Comments property to show all the comments posted by a user.  Then they move on to show all the comments deleted by a user.  Oh no!  It turns out that Comments happened to be the reverse association for DeletedBy and Comments1 happened to be the reverse association for PostedBy.  Now the developer has to go through renaming Comments to CommentsDeleted everywhere.  Or even if the developer gets lucky and picks the right one, they're still stuck with a slightly ambiguous name that it would be a pain to change to something clearer like PostedComments.  Because we don't autoincrement the names, the developer has to look, think and disambiguate the collections *BEFORE* they can use them, ensuring that they use meaningful names from the start.

You may point out that this is really an argument for a rename refactoring, which would allow the developer to change the name in the designer and have it propagated through the code.  And you would be right.  We'd like to get to that position but we're not there at the moment; when we get there, we'll probably do the autoincrement thing.

Feedback 4.  Thanks!

Feedback 5.  Yeah, JD!

Feedback 6.  We're looking at this for 3.0 (we want to keep 2.x .NET 2-compatible).  In the meantime, you can get a notifying collection as follows:

BindingList<Widget> widgets = new BindingList<Widget>();
uow.Find(query, widgets);
// widgets now contains the results of the query, and is bindable

Note that WPF (as of .NET 3.0 SP1 I think) will work with IBindingList as well as INotifyCollectionChanged.  Though if you're in WPF-land you could equally well use an ObservableCollection<Widget> in the above sample instead of a BindingList.

Hi Ivan,

>> Issue 1.  We're open to suggestions as to what would be more helpful behaviour here.  One obvious option is for a sproc always to generate a new result entity type. But this is annoying if you have multiple queries as sprocs which all return the same type but with different criteria.

 I see no reason why you should need to generate a unique entity as output for two stored procs that produce the same output. By that I mean the same columns. As I said, I have two stored procs so far that happily share the entity used to output the result.

I am unsure how other people perform their querying, or if there is an IOC issue here, but when I call a proc that returns, for example, the 5 most expensive products, I know that the List<MyProcResultEntity> is going to be 5 most expensive products.  If I have another proc that returns the 5 cheapest products, I know that the List<MyProcResultEntity> is going to have the 5 cheapest products.  I don't see any problem with re-using an entity for a result - and if a proc has the same output as the whole table, then yeah, reuse the deigner entity.

What we're talking about here though is not the issue I was having.  The designer was failing to generate the output entity for a stored proc when no matching output entity currently existed. It incorrectly picked another entity as the output entity. I.e you press a vending machine button for an apple but it thinks you want an orange.

>> Issue 2.  Scalar procedures are supported in the runtime using the Calculate(ProcedureQuery) method, but we haven't yet got round to them in the designer.  There's no deep reason, just a matter of prioritisation.

Cool, perhaps include that in the output error message you get at the bottom window of the design surface, instead of saying its not supported?

>> Issue 3.  Are you referring to the help file or to the description shown in the designer property grid? 

I am referring to the help file. The deigner property panel notes are adequate thanks, just too technical to know wtf you want without a more thorough explanation/definition.

>> Issues 4 and 5.  These sound like the same issues in opposite directions, and are probably due to a bug in checking associated entities which might be inducing FKs on the selected entity.  I thought we had fixed this but evidently there's a case which has slipped through.

Yes, likely to be the same issue. I will endeavour to call by and show you this.

Issue 6: I will get back to you.  I have not seen that Access Method property. I will have another look, but as I said this was happening in the 20th May nightly.  I will get back to you.

>> Issue 7.  We'll take a look at adding this feature.
Get JD to add it - I'll double his rent till he does it.

 

Feedback 1:  I didn't read the post about the ctrl+wheel thing, cool. I'll check it out.

Feedback 2:  Then perhaps also please add the create table stuff into lightspeed so if a KeyTable table doesn't exist it does it automatically? I have seen the script yes, but I created the table manually once and I ran into that issue, and so has a colleague.  I realise we aren't running the script we've been told to run, but perhaps building the create stuff into lightspeed so "it just works" would create a "better expereince" for the dumbasses out there.

Feedback 3:  JD made a similar argument. I seem to think there is an inherient fallacy in both your arguments (that it doesn't just work out of the box) but you both think there are better reasons for having it designed that way, so that's cool. After all, y'all [should] know best. Refactoring arguments are not the solution to this problem, so they are irrelevant at this stage.

>> Feedback 6: We're looking at this for 3.0 (we want to keep 2.x .NET 2-compatible). 

 Yep good idea.

I'll have a go with var collectionOfWidgets = new ObservableCollection<Widget>; uow.Find(query, collectionOfWidgets);

Thanks Ivan, I'll see you when I get some time to pop by and show you the issue with 1 and 4/5.

Bert

Ivan,

"Issue 6.  Select the sproc result entity and change the Access Method to SelectProcedure.  This will exclude the entity from synchronisation.  You should need to do this only for existing sproc result entities; entities created from sprocs using the current version of the designer should have this property set automatically.  Let me know if this isn't happening for you."

This isn't happening - in fact there is no "Access Method" property on the entity.

Bert

Strange.  That setting has existed for a while, which makes me wonder if perhaps you have an older build.  Can you check the version of the installed Mindscape.LightSpeed DLL and let me know what you see?  Thanks!