From the SORM documentation, it's not really clear and the API does not help.
So, how do I specify a custom column name in an entity? I would also like to change the column name of the primary key for each entity. Is that possible?
Thanks.
No. Changing column names isn't possible because SORM is all about convention over configuration. That's what makes it simple.
The primary key isn't configurable either, but for different reasons.
Related
Context
We are limited by ArangoDB's recommendation against using attribute names starting with an underscore _ https://www.arangodb.com/docs/stable/data-modeling-naming-conventions-attribute-names.html because we want to be certain that any such attribute would not be used by ArangoDB at a later stage.
We could add an attribute
properties:{myproperty1:'abc',_myUnderscoreProperty:'def'},
but in case we would do this for documents representing users, which would have
properties:{_name:'abc',_email:'abc#graphileon.com'},
we would need to be able to create a unique constraint on properties._name. But this does not seem to be possible.
Question
Is this possible or there a workaround?
Yes, it is possible. You can create a unique index on field properties._name
I am using JCo3. While working with BAPI, i get tables that are part of it. While reading metadata of these tables, i will be interested to know which field is the primary key field for the table.
This is important for me while writing persistence related code in java.
Edited:
In fact, I am interested in all BAPIs. For example: BAPI_PO_CREATE1, BAPI_GOODSMVT_CANCEL, etc
Idea is to make this part of the base classes so that the key is identified automatically. I also would like to understand the exceptions, if any.
I found the function module "DDIF_FIELDINFO_GET" useful to get field level metadata. This metadata has information to indicate if it is a Key field.
Good Luck!!
I'd like to add the autoIncrement property for a numeric column in SORM. How do I do that?
There is no way to configure this in SORM and there's a reason: in practice auto-increment property is only needed for id-columns, and SORM manages ids for you.
If you're, however, absolutely sure that you need this, you can always let SORM generate the schema and then alter such details according to your needs with db-administration tool. But again, I'm sure that you're approaching the problem incorrectly. What do you need that for?
(Table)File has many (Table)Words
FK Words.file_id related to a single File.id
Default value of Words.frame is equal to File.frame for that PK/FK
Does this type of default relationship have a name? Examples on getting this setup? (MySQL)
Edit
The reason for this is that words may have the same frame as the file and if they do, we want to use that default, however some may not and need to be set manually. Is this really bad practice to handle it this way as described in one of the answers? Any improvement suggestions?
You may want to use a Trigger. You should be able to mimick the "default value" of Words.frame to be based on the value of another field from the File table.
It doesn't have a name, but feels like denormalization / data duplication to me.
#Daniel Vassallo suggests an insert trigger for this, and I think that would be the best approach as well if this is really what you need.
I have a legacy table that has as a part of its natural key a column named <table_name>_IDENTIFIER and it seems like it would be confusing to create a surrogate key named <table_name>_ID or ID so I'm leaning towards naming it SURROGATE_KEY. All my other tables use the <table_name>_ID syntax. Any better suggestions?
Don't call it SURROGATE_KEY. That is meaningless in any other context. I'd stick with <table_name>_ID. Yes it's a little confusing. But, given your established convention, anything else would be confusing too.
I might suggest that you go with your standard: <table_name>_ID
Eventually, the legacy table will not be the driving force, and it will be the IDENTIFIER column that will look odd, which is what you want, as opposed to that - 'oh yeah, i need to use surrogate_key for that thing instead of id...' moment.
First, I would not include the table name in my columns. A column is an attribute which requires the context of the entity to which it belongs. Having a "name" for example without the context to which it belongs is of no use. You need to know it is a Person's name or a Company name etc. and you have that in the name of the entity itself. Thus, I would not prefix columns with the name of the table in which it is declared.
That leaves you with choices like "Id", "Key", "SurrogateKey", or perhaps "SystemId" which are all equally vague. At least "SurrogateKey" describes what it is which is a bonus. That name will make sense to a DBA but perhaps not a developer (although they should understand the concept). Of those choices, I'd be inclined to use "Id" and find a way to change <table_name>_Identifier to something more descriptive.
In Data Modelling world during drawing ER model, Surrogate key like SURROGATE_KEY (or SURROGATE_ID) will definitely cause pain side-effects when creating Foreign Key Constraint.
I.e. linking parent with child in majority of DM tools via dragg-n-dropping primary key will automatically create identical column in a child generating dups in column names.
To avoid that as a rule of thumb, naming Surrogate key like Table_name.Table_name_ID or Table_name._ID can be good option.
Agreed . . . SURROGATE_ID is not recommended. What all the suggestions seem to be lacking is at the very heart of data management & data modelling best practices: establishing (& consistently using!) naming conventions & value domains. Suggestions:
1. If the database or programming protocol (like .NET which abhors natural primary keys as I've been lead to understand) requires a single, meaningless, integer assigned as a primary key -- a surrogate -- key, then create a value domain of "Id" & define it as data type integer with description of surrogate primary key.
2. When naming attributes/columns, the ONLY columns using the domain "Id" would be surrogate (primary) key columns populated with assigned integer values. No other attributes/columns would be allowed to use the domain "Id", so it would be absolutely clear from the attribute/column name the nature of the values stored AND how those values are begin utilized.
Thanks for the opportunity!