Eduardo wrote:

> In the example above it will generate a Indentifier
> "pk_IDFABRICANTEROTULO_ITEMPRODUTO" that is big for this limitation,
> but you can see clearly that is descriptive and not exagerated !!!!

My suggestion is that the ORM code can ensure uniqueness by prepending
a short identifier, and then can truncate at whatever length is
required. As you say, this is not particularly human readable, and you
could always have a file with a "map" to tell you which field was which.



>  Just want to let my willing that this limit is too low. What I could
> see from my code is that 100 chars is more than enough. Please report
> to development and if it could eventually be added I will be happy,
> if cant I will be happy either.

It would be best for you to report it properly using the
http://www.elevatesoft.com/incident?category=edb page. I wouldn't
expect it to be resolved any time soon, but who knows?

--

Matthew Jones

Matthew,

I will report, thank you...

Again thank you for your considerations, but it is not that obvious for the ORM to automate. And identifiers should identify. not make things difficult to understand, and the ORM try to map the same class structure on the database.

well... thank  you

"Matthew Jones" wrote:

Eduardo wrote:

> In the example above it will generate a Indentifier
> "pk_IDFABRICANTEROTULO_ITEMPRODUTO" that is big for this limitation,
> but you can see clearly that is descriptive and not exagerated !!!!

My suggestion is that the ORM code can ensure uniqueness by prepending
a short identifier, and then can truncate at whatever length is
required. As you say, this is not particularly human readable, and you
could always have a file with a "map" to tell you which field was which.



>  Just want to let my willing that this limit is too low. What I could
> see from my code is that 100 chars is more than enough. Please report
> to development and if it could eventually be added I will be happy,
> if cant I will be happy either.

It would be best for you to report it properly using the
http://www.elevatesoft.com/incident?category=edb page. I wouldn't
expect it to be resolved any time soon, but who knows?

--

Matthew Jones

Eduardo

I apologise in advance. I'm not attacking you personally but this is something I feel quite strongly about.


>That is the same argumentation used on MSDOS era
>
>Now computers, specially servers where I will be running ElevateDB have many gigabytes of memory and terabytes of HardDrive.

>There is no way to automate that, since ORMs, specially Aurelius is based on tagging the class like this: (the class will be persisted automatically by the ORM, there is no control over the database directly)
>
> [Entity]
> [Table('ITEMPRODUTO')]
> [PrimaryJoinColumn('ID')]
> TEntityItemProduto = class(TEntityItem)
> private
> [Association([TAssociationProp.Lazy], [])]
> [JoinColumn('IDFABRICANTEROTULO', [])]
> FFabricanteRotulo: Proxy<TEntityRotuloFabricante>;
>
>
>Not easy to "automate" the way you said. This needs to be manual and "A123" means nothing to me. We lost all the reason of documenting ! An one more thing, SQL Sentences are already very lengthy, what the reason to limit that much?
>
>There is a difference when using full OOP and when you go the old Delphi way direct to the table. We used to do some hacking to overcome limitations in the old way and the code turn quickly a patchwork.
>
>In the example above it will generate a Indentifier "pk_IDFABRICANTEROTULO_ITEMPRODUTO" that is big for this limitation, but you can see clearly that is descriptive and not exagerated !!!!

I've never used an ORM so I'm probably writing gibberish. From what you've said so far Aurelius produces this identifier which seems to be a bit at the front, a column name and a table name with _ as separators and its then passing that over to the database to do something with. If you need to type it then (to me) typing 33 characters is a major pain, and your saying that it produces ones bigger than this (you said the previous example was truncated at 40 characters).

If you don't have to type it then there's no reason that Aurelius shouldn't produce its own internal abbreviation. You also say this is descriptive but I have doubts for two reasons. Firstly it assumes (and this applies to English as well) that the language of the reader is the language of the writer. Secondly the only reason I could parse it even as well as I could is because you provide the breakdown prior to quoting the identifier. I, however, have no idea what the table contains or what the column refers to. I could do a Franglaise translation but that's not useful

I just checked one of my apps and my maximum table name is 14 characters and maximum column name is 24 so I'd also have a problem when the extra pk and the three _ are added.

This is down to TMS to sort out not Tim. I they sell a product as being fit to work with another piece of software its down to them to make sure it is, not the author of the other code to modify it to cope with a third party addition. AND they should warn you of limitations. In UK law at least I'd take you problems as a very good case of a product not being of merchantable quality.

Final point. Lets say Tim extends the limit to 100 characters. What happens when someone using Aurelius starts using 100 character table or column names? We are back here.

Roy Lambert

On 6/30/2014 8:25 AM, Eduardo wrote:
> HOWEVER, looking closely I see that the 40 limit is way low.
> 255 as limit is just fine and understandable, since there is many reasons to not go far 255 due corss platforms  etc etc
>

While i have not had to deal with this on other db systems in a while
there are limits with all of them.

MySQL i believe is still 64 and MS-SQL used to be 128.

We'll see what Tim says but this is not a trivial change IMHO.

Column name is used throughout the system so there likely are
implications on other aspects - things like how many columns are in the
index or how we define key relationships not to mention lot of internal
processing that likely can assume certain max string length.

To me this sounds like one of those balance performance vs flexibility
choices so I'm curious to see what the answer is from Tim - please
update the thread when you hear back.

Good luck.

Raul

hello,
just a side remark:
i ran into this limitation a year or so ago too. i'd like to having self-documentating-identifiers in the db.
tim said it shouldn't be a big issue and considered an identifier-length extension
however it is not of life-importance for me.
but certainly would be nice. 100 would really do it for me ...

Gruetzmacher

>just a side remark:
>i ran into this limitation a year or so ago too. i'd like to having self-documentating-identifiers in the db.
>tim said it shouldn't be a big issue and considered an identifier-length extension
>however it is not of life-importance for me.
>but certainly would be nice. 100 would really do it for me ...

As I said in my post above I feel quite strongly about this. Maybe you can answer a question. Why do people want to type a description into the table / column name?

Somewhat off topic. I can remember from years ago when I was a consultant at one client the product code field was enormous and basically contained the description of the items rather than a product code. I recall that we reduced stockholding by c50% once we rationalised the product codes.

Roy Lambert

hello roy,
it probably is kind of personal taste ... but to me it is timesaving to have a 'speaking' indexname/constraint. i could lookup the used columns in edbmgr, but it is way nicer to see it directly. it opens chances for meta-programming as well: write documentation for table via the catalog-data ... people from outside looking into your database quite likely envy the brain behind a systematic approach to naming (i might be wrong on this ...). that's at least something i look at when joining other projects ...

small things ...

Roy Lambert wrote:

Gruetzmacher

>just a side remark:
>i ran into this limitation a year or so ago too. i'd like to having self-documentating-identifiers in the db.
>tim said it shouldn't be a big issue and considered an identifier-length extension
>however it is not of life-importance for me.
>but certainly would be nice. 100 would really do it for me ...

As I said in my post above I feel quite strongly about this. Maybe you can answer a question. Why do people want to type a description into the table / column name?

Somewhat off topic. I can remember from years ago when I was a consultant at one client the product code field was enormous and basically contained the description of the items rather than a product code. I recall that we reduced stockholding by c50% once we rationalised the product codes.

Roy Lambert

Roy,

No need to apologize, it is all technical stuff.

I have added the information of using TMS Aurelius as of interest since I know there are more Aurelius + ElevateDB users, and from the thread I have posted in their forum I just find out some guys that run on the very same problem.

It is not a "who is the fault". I am customer of both products. And for me, like I said before, the limit is low. I can easily run into problems with this limit alone, no need of Aurelius.

However I am not looking for fight for that !!!!! I was just looking for the possibility of changing that. AND giving some reasoning that could eventually touch the heart of Tim for changing that.... that is all

So, no need to create a defensive barrier to protect the software.... I am extremely content with it. Just a little disappointed with this limit.

I meant descriptive because if you read it and dont have to take a look on your code to understand that it says, means descriptive;

for example:
CONSTRAINT "PK_MOVCAIXAPDVITEMS" PRIMARY KEY ("ID"),
CONSTRAINT "FK_MOVCAIXAPDVITEMS_DOCMOV_IDDOCMOV" FOREIGN KEY ("IDDOCMOV") REFERENCES "DOCMOV" ("ID")
  ON UPDATE NO ACTION ON DELETE NO ACTION,
CONSTRAINT "FK_MOVCAIXAPDVITEMS_CONTFUNCIONARIO_IDFU" FOREIGN KEY ("IDFUNCSUPERVISOR") REFERENCES "CONTFUNCIONARIO" ("IDCONTATO")
  ON UPDATE NO ACTION ON DELETE NO ACTION

This is a case where I have alread reduced the table name and the limit is raised.

Since I am creating a GIANT software, where I am relying in features that is only possible with an ORM together, it is important for me and I know that for others also.

Aurelius for example creates Table INHERITANCE, that is for example:

TableItem

TableProduct(TableItem)

TableService(TableItem)

And all the fields and properties comes from on table to another. In the database is generated separated tables and linked with the help of this foreign keys. That needs a mapping that cause to create those identifiers that are more descriptive.

That is very cool feature, the ability of inheritance opens up the door to easily create a software that can be customizable. No need to be creating separated tables, or many versions of the software.

So I am creating many levels of inheritance according to the need and is working very well with ElevateDB

Again, there is no need to be so protective of the software. It is technical, and a change must come with a good reason. There is no need to cite laws for that....

Raising limits is what ALWAYS happens in ANY software and HARDWARE since it was created!!!!

My first PC-XT came with 128km ram, and could not expand it... Now I am working with 8gb and need to change my notebook because there is no way to expand... sad. Next notebook I will get with possibility of much more.

Same thing for 32bits and 64bits, ElevateDB needed to adapt to 64bit because of what? Raising limits!!!!

So Identifier with 40 is too short... need to raise the limit.... I do no believe there is internal code limitation due to the quality of the source code from Elevate. I believe this is question of memory usage. And was decided that 40 is fine. 100 is much better 255 is the sky. After that could comes with limitations in other platforms (like android maybe)

Eventually it could be a switch on the source code, that I could recompile the code for bigger limit. Not the best but that works also.

I posted a request for that, who knows, eventually I get lucky and the change comes in some future version, I expect that since I see that in the future that will limit the clarity of the Identifiers generated.

Thank you Roy for all your attention.

Roy Lambert wrote:

Eduardo

I apologise in advance. I'm not attacking you personally but this is something I feel quite strongly about.


>That is the same argumentation used on MSDOS era
>
>Now computers, specially servers where I will be running ElevateDB have many gigabytes of memory and terabytes of HardDrive.

>There is no way to automate that, since ORMs, specially Aurelius is based on tagging the class like this: (the class will be persisted automatically by the ORM, there is no control over the database directly)
>
> [Entity]
> [Table('ITEMPRODUTO')]
> [PrimaryJoinColumn('ID')]
> TEntityItemProduto = class(TEntityItem)
> private
> [Association([TAssociationProp.Lazy], [])]
> [JoinColumn('IDFABRICANTEROTULO', [])]
> FFabricanteRotulo: Proxy<TEntityRotuloFabricante>;
>
>
>Not easy to "automate" the way you said. This needs to be manual and "A123" means nothing to me. We lost all the reason of documenting ! An one more thing, SQL Sentences are already very lengthy, what the reason to limit that much?
>
>There is a difference when using full OOP and when you go the old Delphi way direct to the table. We used to do some hacking to overcome limitations in the old way and the code turn quickly a patchwork.
>
>In the example above it will generate a Indentifier "pk_IDFABRICANTEROTULO_ITEMPRODUTO" that is big for this limitation, but you can see clearly that is descriptive and not exagerated !!!!

I've never used an ORM so I'm probably writing gibberish. From what you've said so far Aurelius produces this identifier which seems to be a bit at the front, a column name and a table name with _ as separators and its then passing that over to the database to do something with. If you need to type it then (to me) typing 33 characters is a major pain, and your saying that it produces ones bigger than this (you said the previous example was truncated at 40 characters).

If you don't have to type it then there's no reason that Aurelius shouldn't produce its own internal abbreviation. You also say this is descriptive but I have doubts for two reasons. Firstly it assumes (and this applies to English as well) that the language of the reader is the language of the writer. Secondly the only reason I could parse it even as well as I could is because you provide the breakdown prior to quoting the identifier. I, however, have no idea what the table contains or what the column refers to. I could do a Franglaise translation but that's not useful

I just checked one of my apps and my maximum table name is 14 characters and maximum column name is 24 so I'd also have a problem when the extra pk and the three _ are added.

This is down to TMS to sort out not Tim. I they sell a product as being fit to work with another piece of software its down to them to make sure it is, not the author of the other code to modify it to cope with a third party addition. AND they should warn you of limitations. In UK law at least I'd take you problems as a very good case of a product not being of merchantable quality.

Final point. Lets say Tim extends the limit to 100 characters. What happens when someone using Aurelius starts using 100 character table or column names? We are back here.

Roy Lambert

Eduardo

>No need to apologize, it is all technical stuff.
>
>I have added the information of using TMS Aurelius as of interest since I know there are more Aurelius + ElevateDB users, and from the thread I have posted in their forum I just find out some guys that run on the very same problem.
>
>It is not a "who is the fault". I am customer of both products. And for me, like I said before, the limit is low. I can easily run into problems with this limit alone, no need of Aurelius.
>
>However I am not looking for fight for that !!!!! I was just looking for the possibility of changing that. AND giving some reasoning that could eventually touch the heart of Tim for changing that.... that is all
>
>So, no need to create a defensive barrier to protect the software.... I am extremely content with it. Just a little disappointed with this limit.

If you review some of my posts you'll see I'm happy to attack Tim's software

One of the tings I was trying to do is point out who, in my opinion, is responsible to resolving the situation. Its one thing to ask Tim for an enhancement, its another to ask him to resolve a problem caused by someone else's software.

The other thing is that whilst I agree that capabilities are improving the software industry seems fixated on ensuring that the improvements in hardware are negated by "improvements" in software. Either additional features, more bells and whistles, or "higher level" approaches all of which means that the end user generally gets less out of t than they should do - I AM AN OLD FART!


>I meant descriptive because if you read it and dont have to take a look on your code to understand that it says, means descriptive;
>
>for example:
>CONSTRAINT "PK_MOVCAIXAPDVITEMS" PRIMARY KEY ("ID"),
>CONSTRAINT "FK_MOVCAIXAPDVITEMS_DOCMOV_IDDOCMOV" FOREIGN KEY ("IDDOCMOV") REFERENCES "DOCMOV" ("ID")
> ON UPDATE NO ACTION ON DELETE NO ACTION,
>CONSTRAINT "FK_MOVCAIXAPDVITEMS_CONTFUNCIONARIO_IDFU" FOREIGN KEY ("IDFUNCSUPERVISOR") REFERENCES "CONTFUNCIONARIO" ("IDCONTATO")
> ON UPDATE NO ACTION ON DELETE NO ACTION
>
>This is a case where I have alread reduced the table name and the limit is raised.

Maybe if you translated that into English for me I could understand better <vbg>

As a typical brit I use one language fairly badly!

>Since I am creating a GIANT software, where I am relying in features that is only possible with an ORM together, it is important for me and I know that for others also.

Amongst other things I am incurably curious - what is your giant software about?

>Aurelius for example creates Table INHERITANCE, that is for example:
>
>TableItem
>
>TableProduct(TableItem)
>
>TableService(TableItem)
>
>And all the fields and properties comes from on table to another. In the database is generated separated tables and linked with the help of this foreign keys. That needs a mapping that cause to create those identifiers that are more descriptive.
>
>That is very cool feature, the ability of inheritance opens up the door to easily create a software that can be customizable. No need to be creating separated tables, or many versions of the software.
>
>So I am creating many levels of inheritance according to the need and is working very well with ElevateDB

Not sure I understand that (I've never used an ORM) but it sounds good. One day I may download Synopse's mORMot and have a play

>Again, there is no need to be so protective of the software. It is technical, and a change must come with a good reason. There is no need to cite laws for that....

As above I'm not protective of ElevateDB, I just think that this should be laid at TMS' door since they have apparently miss-sold you a product.

>Raising limits is what ALWAYS happens in ANY software and HARDWARE since it was created!!!!
>
>My first PC-XT came with 128km ram, and could not expand it... Now I am working with 8gb and need to change my notebook because there is no way to expand... sad. Next notebook I will get with possibility of much more.
>
>Same thing for 32bits and 64bits, ElevateDB needed to adapt to 64bit because of what? Raising limits!!!!

No, in that case, not raising limits, increasing capabilities.

>So Identifier with 40 is too short... need to raise the limit

I would rephrase that - if 40 character identifiers are concatenated they no longer fit into a 40 character field. This is not a surprise As I said in the last post if its increased (and it would have to be across the board) how long before someone hits the new limit. There is always someone out there who will do that.

>.... I do no believe there is internal code limitation due to the quality of the source code from Elevate. I believe this is question of memory usage. And was decided that 40 is fine. 100 is much better 255 is the sky. After that could comes with limitations in other platforms (like android maybe)

Well for ElevateDB why not go for the maximum permitted - 1024?

>Eventually it could be a switch on the source code, that I could recompile the code for bigger limit. Not the best but that works also.

Yuck - that's a bit of a support nightmare

>I posted a request for that, who knows, eventually I get lucky and the change comes in some future version, I expect that since I see that in the future that will limit the clarity of the Identifiers generated.

Everything is possible, and Tim does listen to requests.


Roy Lambert

Give a try in Aurelius, it does less than mORMot but it is the amount that i need..  and they are improving... when XData got lauched it will be closer to what mormot is....

However seems much simplier, since it is based on pure classes and mormot you need to inherit their classes.

mormot works from delphi 7 to the last, Aurelius only with 2010 and up since it uses the last advances on the language, what I prefer, making the source code easier and more readable, at least for who liles OOP a lot...

About the giant software, I said already, it is a ERP, but an Inheritable one, where "levels" of refinement on the data are added in an inheritance way. Right now, my ITEM "table" have 4 levels. Depending on the need you have, you choose one of the levels. This way you can have a light software, or a mamut, depend on what you use and install. But the source code is the same.

Aurelius is not database dependent, can use many. I just prefer ElevateDB because I trust, and that is SO easy to install (can we call install?), so it is easy to deploy in simple environments. But works nice in places where the TI guys complain a lot.

After I have started working with Aurelius I cannot come back ! There is a learning curve, and you will have to walk with your dog to have some ideas... because is another world. But is easier to structure the application.

regards,