I am currently looking for a complete list with description of the available properties for Sails models' attributes.
I run Sails 1.2.3.
Some attributes are listed here: https://sailsjs.com/documentation/concepts/models-and-orm/attributes
And validation rules are available here: https://sailsjs.com/documentation/concepts/models-and-orm/validations
The problem is that there are some attributes in the models that are not listed in those pages nor anywhere else in the manual (for what I saw.)
An example of this is the 'User' model, which is created by default.
The attribute 'password' has the 'description' and 'protect' properties for which I haven't found any definition.
I suppose that there are other properties that I don't know of and are not listed in the previous pages.
Making a search using for "protect" using grep, I did find a file listing all available properties
node_modules/waterline-schema/accessible/valid-attribute-properties.js
The problem is that this is only a list and there are no description of how those attributes work.
I checked on DuckDuckGo and Google to no avail.
My guess is that there is a part of the manual describing properties for more general objects than models and that these properties can be used in the models as well.
I would have expected that this information would be in the manual, but I haven't found it. If I find a resource with these descriptions I intend to make a pull request for Sails manual.
Thank you in advance and have a good day.
Nemo.
Related
Hi I am new to Apache Atlas . And I am facing a problem.
I want to create a hive_table entity type manually but in Entity type drop downs its showing only "hdfs_path"
Can anyone let me know how I can use a custom entity type in apache Atlas.
And can anyone provide me a good documentation part or tutorial apart form Apche Atlas site.
Here is the photo where I want to add a new entity type
TL;DR: you need to apply the following setting to atlas-application.properties, and restart:
atlas.ui.editable.entity.types=<your entity types>
Note that <your entity types> can be a comma-separated list, like hdfs_path,kafka_topic or, to just allow all Types to be created and edited via the UI, use a star *.
I guess the reason for this restrictive default is because metadata in Atlas is normally synchronised from other systems using hooks and bridges. So in order to keep the metadata "consistent" (i.e. prevent the risk of people creating metadata entries in Atlas which do not correspond to actual data assets existing in the referenced systems), by default editing Entity Types via the UI is locked down.
Reference: https://issues.apache.org/jira/browse/ATLAS-3237
hive_table entity should be synced using import scripts.
"hdfs_path" is not synced automatically unless they belong to lineage, hence the option to create them manually.
However, if you want to create them manually, please check the following link, which has the steps:-
https://community.cloudera.com/t5/Support-Questions/How-to-create-hive-table-entity-in-Apache-atlas-using-REST/td-p/173644
As far as I can tell there is no way to specify that an existing schema class should be used when a matching label is specified but default to the general V/E classes otherwise. I have few custom E sub classes that I would like to use but I don't want other edge labels to cause the creation of additional sub classes. The API I'm using is TinkerPop-based and I cannot explicitly specify vertex/edge classes.
The OrientConfigurableGraph.setUseClassForEdgeLabel(boolean) setting is an all or nothing option. If it is set to true schema classes are created for all labels and if it is set to false new vertex/edge instances are set to the general V/E classes even if there is a matching class. Am I correct about this? I would like a configuration option that allows the use of matching schema classes if they are available in the schema but without automatically creating others when there is no match. I'm using version 2.1.8.
After browsing the OrientDB v2.1.x reference documentation and javadocs, i couldn't find a configuration option that configures the graph the way you want, so what you can do, is to open a ticket in the issue tracker at github and request that feature.
Although, in the meantime, you can control this programatically with the Graph API with the custom vertex/edges functions, as explained in the documentation, not ideal, as you need to control this programatically, but for now is the closest i could find.
I am trying to add a Tagged Value in Enterprise Architect which allows the selection of one or more values, a multi-select tagged value type in effect.
Is this possible?
Xstian's answer is partially correct if you're working with profiles. However, it only provides you with a select-from-a-list tag type (and you should not import profiles directly into a project, you should create MDG Technologies instead).
EA also allows you to create what are known as structured tagged values. These come in different flavours, and allow you to select a value from an enum list, a file name from a browser dialog, a date from a calendar, and many others -- including classes in the same model.
These tagged value types are configured in Settings - UML Types - Tagged Value Types. The syntax is described in the help file under Extending UML Models - MDG Technology SDK - Tagged Value Types - Predefined Types (but note that you do not need to create an MDG Technology or even a profile for these tag types to work).
You can add to any model element more than one tagged value of the same name - each of them can have different value. Together they logically constitute "set of values" (i.e. multi-valued tag).
Yes it is.
I solved in this way.
You should create a your Stereotype
http://www.sparxsystems.com/enterprise_architect_user_guide/10/extending_uml_models/addingelementsandmetaclass.html
(e.g. see image)
You should export this profile in XML and import it into EnterpriseArchitect
http://www.sparxsystems.com/enterprise_architect_user_guide/10/extending_uml_models/importingprofiles.html
Add this stereotype to your class,connector, etc
I hope I've given you all the answers about your question
i was just trying to achieve a N:M relation between two of my Domain Models with an attribute.
I tried this Tutorial ( sorry, it's german, but the code is fine. ) and everything works fine in the backend and the database (datarecords are created correctly, relations are visible in backend/tca config).
BUT: When I try to create a Model/Repository/Controller/Plugin ( all with minimal basic configurations, just for testing the output, so nothing fancy here ) and try to output my "firma" with the RepositoryMethod->findAll() I get an Error in SQL Syntax.
Extbase seems to access the wrong tables. Normally the SQL statement should ask for the mitarbeiterid/firmaid in the relation table. But the SQL-Error reveals that Extbase tries to find the column "firmaid" / "mitarbeiterid" in the "mitarbeiter"-table, where those columns do not exist.
Does anyone of you know if this can be fixed, or am I missing something from the tutorial (I'm aware that the first tutorial has some typing errors, but that'S not the problem :( ) ? I tried another tutorial IRRE Tutorial which is basically the same, just a bit more extended. Same SQL-Error in here. What has to be done to get some output in the frontend of these datarecords ?
Thanks in advance.
The tutorial seems to be outdated. seems to be more up to date and actually using extbase/fluid.
But lucky you, its not that hard to achieve what you are aiming for. You need to check this list. Make sure that
Your class names, table names and folder structure are in synch with extbase expectations
You have two domain models of which both have a property that contains a objectStorage that contains instances of the other object
You have configured your TCA for both tables to use a mm table for the property containing the objectStorage
I would like to experimentally apply an aspect of encapsulation that I read about once, where an entity object includes domains for its attributes, e.g. for its CostCentre property, it contains the list of valid cost centres. This way, when I open an edit form for an Extension, I only need pass the form one Extension object, where I normally access a CostCentre object when initialising the form.
This also applies where I have a list of Extensions bound to a grid (telerik RadGrid), and I handle an edit command on the grid. I want to create an edit form and pass it an Extension object, where now I pass the edit form an ExtensionID and create my object in the form.
What I'm actually asking here is for pointers to guidance on doing this this way, or the 'proper' way of achieving something similar to what I have described here.
It would depend on your data source. If you are retrieving the list of Cost Centers from a database, that would be one approach. If it's a short list of predetermined values (like Yes/No/Maybe So) then property attributes might do the trick. If it needs to be more configurable per-environment, then IoC or the Provider pattern would be the best choice.
I think your problem is similar to a custom ad-hoc search page we did on a previous project. We decorated our entity classes and properties with attributes that contained some predetermined 'pointers' to the lookup value methods, and their relationships. Then we created a single custom UI control (like your edit page described in your post) which used these attributes to generate the drop down and auto-completion text box lists by dynamically generating a LINQ expression, then executing it at run-time based on whatever the user was doing.
This was accomplished with basically three moving parts: A) the attributes on the data access objects B) the 'attribute facade' methods at the middle-tier compiling and generation dynamic LINQ expressions and C) the custom UI control that called our middle-tier service methods.
Sometimes plans like these backfire, but in our case it worked great. Decorating our objects with attributes, then creating a single path of logic gave us just enough power to do what we needed to do while minimizing the amount of code required, and completely eliminated any boilerplate. However, this approach was not very configurable. By compiling these attributes into the code, we tightly coupled our application to the datasource. On this particular project it wasn't a big deal because it was a clients internal system and it fit the project timeline. However, on a "real product" implementing the logic with the Provider pattern or using something like the Castle Projects IoC would have allowed us the same power with a great deal more configurability. The downside of this is there is more to manage, and more that can go wrong with deployments, etc.