Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - Uffe

Pages: 1 [2] 3 4 ... 124
16
Bugs and Issues / Re: User created multiple times
« on: December 25, 2020, 12:41:35 am »
No, the creation scripts have been updated. It's just not mentioned in the client release notes.
Didn't see any patch scripts, but I might have missed them.

The other option is that they reverse the change and go back to the old Domain\userName

I don't see how that's an option. EA can't decide what the domain controller returns.

/U

17
Bugs and Issues / Re: Package.Alias not updated before Package.Update
« on: December 24, 2020, 08:12:24 pm »
Years ago I adopted the convention of never using a Package object's pass-through properties which are really in Element, but always using the explicit Package.Element.Alias etc.
I don't remember precisely what prompted this, but it was something like what you describe.

/Uffe

18
Bugs and Issues / Re: User created multiple times
« on: December 24, 2020, 08:08:45 pm »
According to the schema release notes, they've increased the size to 255. I still say that's probably insufficient, but it should be enough for most users so should make the problem occur less frequently. Near enough, good enough.

The client history doesn't mention the fact that there is a new version of the DBMS creation scripts, which you must use to set up a DBMS repository. The base projects have been updated, so if you update the client but not the DBMS creation scripts (which are, of course, a separate download), and then try to transfer a newly created file-based project to a DBMS project initialized with the old scripts, well who knows.

/Uffe

19
Bugs and Issues / Re: Bug: File Path too short
« on: December 21, 2020, 11:42:35 pm »
Have I missed something?  Wouldn't the simplest answer be to use a service like tinyurl.com.  You get a short URL so you can add clickable links and it automatically redirects to the target you want.
There are good reasons why you wouldn't want to use such a service. Security and robustness spring immediately to mind. The existence of such services is not something that can be relied upon, and therefore not a reason for this bug to persist.

Taking off in a slightly different direction, what if users just change the schema themselves?

The handling of the t_secuser.UserLogin size issue, which in 15.6.1556 prompted the change Security User login names will now truncate to the database field length rather than a fixed value, to accommodate users extending the field in the Database, suggests that user hacking of the schema is encouraged and the tool will, where necessary, be updated to handle such hacks.

This situation appears to be identical -- an nvarchar that is too short for the purpose. So is this an occasion where hacking is encouraged?

Or will this hack have bad consequences which will not be accomodated in future releases?


/Uffe

20
Ring. Hat. Toss.

In my opinion Sparx is too complex to use for large companies (Gartner's target audience).  Multinationals want cheap generic employees doing cheap generic work as cheaply as possible, and just good enough to get by (especially in IT).  To use EA to anywhere near its capabilities you need to REALLY understand UML AND SQL (for model queries) AND its API.
If you are a professional, Sparx is a great (maybe the best) tool.  It's just that it's not part of Gartner's target audience.

See, now that's interesting. I see it a little differently.

In my view EA is an enthusiast's tool -- not a professional's. In order to make good use of EA you need someone in the organization who knows the ins and outs of the tool. It's not enough to know the modelling language.

EA is a toolkit. It's a rag-bag of features that don't work well together, and which sometimes are different attempts to implement the same functionality. Unless you intend to work only within the tool, it comes with nothing to help you in any given usage scenario: no usable project setups, model structures, or document templates. What's there is all demo-level stuff. On the IT side of things, EA integrates poorly and clunkily. And even the extension mechanisms are limited: you can access the most basic functions through the API, but only a very small number of the high-level ones.
Navigating this quagmire requires deep insight, which must either be built up within the organization, or purchased from a third party. All of this makes EA a far more expensive tool to use than the purchase price would suggest.

As to this Gartner stuff, I don't think it's necessarily a big deal in and of itself. It's just marketing. If Sparx have taken the positive decision not to cooperate with Gartner for this report, that can be simply because they haven't see enough return on that in previous years.

But I am concerned for EA's future.

To some extent, the failure of EA is the failure of UML: it promised effective communication in all things software, but very quickly turned its back on all real world issues involved in software development and instead disappeared up its own backside, issuing new versions of the language standard with ever more complex syntax and semantics, but making no attempt at implementing profiles for any architectural patterns, design principles, or even source code languages. So if you take the trouble of teaching all stakeholders a completely alien symbolic language, you can then use it to express... nothing that actually matches the reality you encounter at any stage of the software development process.

The failure in both cases is one of attitude. Instead of facing inwards and trying to come up with more clever bits to bolt on, there needs to be a 180o shift of focus outwards to what the tool is actually used for. No one is ever going to do their project planning in EA, but they will use it to draw UML diagrams, and those diagrams need to be made easily available in other contexts.

I firmly believe that what EA needs is not yet more superficial features spread like manure across a weedy field. What it needs is, at the front end, packaging of sets of features for different real-world scenarios, with profiles, document templates, project structures, user security roles, version control setup, integrations with other tools, and locking off of extraneous features. At the back end, it needs optimization in the data layer, a complete overhaul of the IT integration principles and a substantially expanded API.

I also believe that we the community could help Sparx in this. We have the expertise in using this tool in the wild; Sparx don't. They don't supply their own consultants, and internally, they only develop one piece of software so even if they do eat their own dog food it's only one flavour of one brand.
So we could actually help in prioritizing what improvements to make and what features to focus on for a given goal, eg reducing cost of adoption in mid-to-large organizations. But that would of course also require a higher level of community commitment from Sparx.

Well, that's what I think anyway.


/Uffe

21
Bugs and Issues / Re: User created multiple times
« on: December 21, 2020, 08:27:19 pm »
Hi again,


You're barking up the wrong tree here, lads. The max length of an e-mail address isn't the issue.

We are not talking about e-mail addresses, but about Windows accounts. These come in two forms, the older Down-Level Logon Names (DomainController\UserName) and User Principal Names (UserName@Domain).

UPN account names are on the same form as an e-mail address, but they are not the same thing and do not obey the rules in RFC 5321.


/Uffe

22
General Board / Re: Access to EA with the AD account from outside (PCS?)
« on: December 17, 2020, 10:12:06 pm »
For future reference, I should also add that it's not the 40-character limit of t_secuser.UserID that gets broken, but the 32-character limit of t_secuser.UserLogin.

.UserID holds a GUID. That's fine in a 40-character space, it's a GUID and 40 characters is what's used for GUID columns throughout the EA schema. The GUID is the in-project identity of the user, it's nothing to do with anything external.
If you're using Domain or OpenID authentication, the external user name is stored in .UserLogin. That's what breaks, and since it's only 32 characters that's hardly surprising.

More discussions on this particular topic in this thread.

/U

23
General Board / Re: Access to EA with the AD account from outside (PCS?)
« on: December 17, 2020, 10:04:44 pm »
Hello,

More on this...  When we add a new user as AD-Linked, instead of getting <domain>\User we got the user's email address.  Unfortunately, it breaks the 40 character barrier in t_secuser.UserID and consequently, he CAN'T Log in!

Strictly speaking, and I know you don't mind speaking strictly, it's not an e-mail address but a user name in User Principal Name format, as opposed to the Domain\User style, aka Down-Level Logon Name. UPN user names are on the same form as e-mail addresses, but they aren't the same thing.

Quote
This needs to be fixed!  If you're going to use email address, 40 chars are NOT enough!

No indeed. I'd set it to no less than 360 and would recommend you go to 512 or something. This isn't something that needs to be hard-optimized in the schema -- it's not referenced often and there aren't typically thousands of users in a project -- and you don't want to have to deal with it more than once.


/Uffe

24
Bugs and Issues / Re: User created multiple times
« on: December 17, 2020, 09:53:57 pm »
I've just checked, and new projects created with 1556 will have a 32-char UserLogin, both in Access/JET4 and Firebird.
Hmm I might need to check if the project transfer still works in that case... ???
That might start throwing errors if the EABase still contains the 32 character UserLogin and I have users with longer logins.

Sounds like a very good idea.

But I think your 255 characters is too short.

An FQDN caps out at 255. Then you need one for the separator (  @  or  \  ), and then the user logon name on top of that.
Max length for a logon name that I've seen on a Microsoft page is 104 (more than 64 "not practical") and although that's for Server 2000 they aren't likely to have reduced it in the intervening 20 years.

So to be safe, I'd make it 360 characters. Possibly more, indeed why not take it up to 512?

It is quite possible that the actual limit is lower in any specific installation, but remember, the EA schema is not what should dictate any IT policies in your organization: it needs to be no more restrictive than the other components in your IT environment. 255 sounds needlessly optimistic to me in the general case. You don't want to have to deal with this problem more than once.


/Uffe

25
Bugs and Issues / Re: User created multiple times
« on: December 17, 2020, 08:43:35 pm »
The release note doesn't say whether the client, or the supplied base project, has been updated so that projects created as of 15.2.1556 will have the correct length for this field. Most likely they won't.

I've just checked, and new projects created with 1556 will have a 32-char UserLogin, both in Access/JET4 and Firebird.

26
Bugs and Issues / Re: User created multiple times
« on: December 17, 2020, 08:24:20 pm »
According to the accepted answer on Stackoverflow the maximum size is 254, so I was right on the spot  ;D

Off by one. Most common error in programming. :)

On the serious side, I think this is a decidedly odd thing for a supplier to do. This is a bug which has been shown to break the tool in the wild, and which has a simple solution. Instead of rolling out that solution, they encourage users to go hacking the database schema by themselves.
Those users who find the solution, that is -- a one-liner in the release note for one particular version isn't much use on its own, so users would have to find this thread to understand that this is something they can, and should, do. No help on how to do it either, for any of the DBMSes EA supports, and no patcher script to download and run.

The release note doesn't say whether the client, or the supplied base project, has been updated so that projects created as of 15.2.1556 will have the correct length for this field. Most likely they won't.

So are Sparx perhaps putting schema updates on the shelf for now to be included in 16.0?


/Uffe

27
Hi Michiel,

My first attempt failed but I was wondering if fragments with SQL code are correctly called from DocumentGenerator.DocumentElement....

Fragments work the same when called from scripts as when part of regular (F8) document generation. Which is to say, you cannot pass a fragment to DocumentElement() directly, but if you pass a regular template and that template includes a fragment, the fragment is applied correctly.

NB: This applies to SQL fragments, but script fragments won't work when referenced from a generation script because EA's script management is broken and can only deal with one script at a time.


/Uffe

28
Hello,


XMI exports don't include version control settings or baselines either, do they? And I for one don't think they should, because they're exports of model content.

It might make sense to be able to export all audit data from a package, but it shouldn't be part of the model content export.
And if you want to make a complete snapshot of a project, you can do a project transfer.


/Uffe

29
Hi Avi,

The problem there is that EA's browser only has limited multiselect support. You can only multiselect elements if they're in the same package.
Since the elements you convey in an information flow don't have to be located in the same package, EA can't select them directly from the context menu.

/Uffe

30
Hi again,

Yes. You're not traversing the package structure properly.
child is actually the "Models" root node, not the "StateMachineDiagram1" view.

/Uffe

Pages: 1 [2] 3 4 ... 124