In my model I have a store named MyModel.MyStore. Once the BOM producer run, it becomes a constant whose name is MyModel_MyStoreStoreName
Given a simple producer, I want to add the persistence statement; usually
CodeFluent.Runtime.CodeFluentPersistence persistence = CodeFluentContext.Get(MyModel.Models.Constants.MyModel_MyStoreStoreName).Persistence;
From the entity I've seen I can get the defined store name, but I didn't find any way to have the final store name as constant; i.e. MyModel_MyStoreStoreName;
One way I found is to iterate through methods to filter statement I'm interested in. What is the most reliable way to fetch/build this persistence statement ?
Thanks for your answer,
The Business Object Model Producer (BOM) use the following method to generate the name of the constant:
CodeFluent.Producers.CodeDom.CodeDomLocal.GetStoreFieldName(entity.Store.Name)
Related
I have to use Orion (NGSI v2), and I have a question about the name of entityId of my context;
could I use a simple ID or URN (like NGSI-LD spec)?
What is the best practice?
Thanks a lot
From a NGSIv2 point of view, any entity ID that complies with the identifiers syntax restrictions is valid.
Having said this, in general the simpler entity ID, the better from an integration point of view. For instance, if you are persisting context data using Cygnus sink for PostgreSQL, note that PostGresSQL could use tables which name includes the entity ID (for instance, if the dm-by-entity-database-schema DM is used, see this reference).
Thus, better to use simple entity IDs than URN-like entity IDs, from my point of view.
I think it is better to use URIs for your entities, your path to Linked Data will be smoother. The problem with table names should be fixed by the data storage component for instance by calculating a hash of the URI and converting it to the proper alphabet supported by the database concerning table names ...
C# 9 introduces record reference types. A record provides some synthesized methods like copy constructor, clone operation, hash codes calculation and comparison/equality operations. It seems to me convenient to use records instead of classes in general. Are there reasons no to do so?
It seems to me that currently Visual Studio as an editor does not support records as well as classes but this will probably change in the future.
Firstly, be aware that if it's possible for a class to contain circular references (which is true for most mutable classes) then many of the auto generated record members can StackOverflow. So that's a pretty good reason to not use records for everything.
So when should you use a record?
Use a record when an instance of a class is entirely defined by the public data it contains, and has no unique identity of it's own.
This means that the record is basically just an immutable bag of data. I don't really care about that particular instance of the record at all, other than that it provides a convenient way of grouping related bits of data together.
Why?
Consider the members a record generates:
Value Equality
Two instances of a record are considered equal if they have the same data (by default: if all fields are the same).
This is appropriate for classes with no behavior, which are just used as immutable bags of data. However this is rarely the case for classes which are mutable, or have behavior.
For example if a class is mutable, then two instances which happen to contain the same data shouldn't be considered equal, as that would imply that updating one would update the other, which is obviously false. Instead you should use reference equality for such objects.
Meanwhile if a class is an abstraction providing a service you have to think more carefully about what equality means, or if it's even relevant to your class. For example imagine a Crawler class which can crawl websites and return a list of pages. What would equality mean for such a class? You'd rarely have two instances of a Crawler, and if you did, why would you compare them?
with blocks
with blocks provides a convenient way to copy an object and update specific fields. However this is always safe if the object has no identity, as copying it doesn't lose any information. Copying a mutable class loses the identity of the original object, as updating the copy won't update the original. As such you have to consider whether this really makes sense for your class.
ToString
The generated ToString prints out the values of all public properties. If your class is entirely defined by the properties it contains, then this makes a lot of sense. However if your class is not, then that's not necessarily the information you are interested in. A Crawler for example may have no public fields at all, but the private fields are likely to be highly relevant to its behavior. You'll probably want to define ToString yourself for such classes.
All properties of a record are per default public
All properties of a record are per default immutable
By default, I mean when using the simple record definition syntax.
Also, records can only derive from records and you cannot derive a regular class from a record.
Here's a scenario I need to execute to throw the optimistic lock exception in case if something has changed underneath between the time I read from the DB and by the time I actually writes it back. I have a project that defines it's own persistence entities and unit. The EntityManager is defined with the extended persistence context. It define a bunch of persistent entities.
Now I have a dependency on some jar file and now this jar file also defines some persistence entities and it's own persistence unit(in persistence.xml file) and entityManager. The entityManager here also is defined with extended persistence context.
Both the persistence unit are pointing to the same database and same schema/library(DB2). THere are some persistent entities that are common between both the persistence units i.e. they refer to the same underlying table but since they are coming from two different jars they have a different name/package structure and a different set of keys defined as a composite primary key.
The scenario is and I need to read an entity from one of the entityManager and then write/update using the different entity manager. Since I am running this in a single transaction the persistence context propagates but since these are 2 different persistence units and each defines a different name/package structure for the same underlying table, even I read from one of them and try to save from the other, the second entity manager saves this as a new entity as if it doesn't exist in the table. So even if the data has changed for the same row in the DB between the time I read it from the first entity Manager and the time I try to write using different entity manager it doesn't throw the optimistic lock exception, it just saves it as it is.
I tried my best to explain the scenario but please don't hesitate to ask in case of query. Also, I believe if you have 2 different PU that defines persistent entity with different name for the same underlying table, you just cannot read from one em and have the other em know that since the underlying table is same, and since this row has been read by different em so let convert this entity the way that second PU defines it and when tries, the second em tries to compare the data in the table first if something has changed since the very first time the first em read from the same table and if something has changed then to throw the optimistic lock exception.
Can a Orion Context Broker entity have two attributes with the same name but different type?
If yes, is it controlled by Orion? Is an error returned when such an entity is created?
If no, what happens when a convenience operation tries to get the value of one of the 2 attributes (AFAIK, the attribute type is not passed in the operation).
From Orion 0.17.0 on, type is no longer used to identify an attribute. Thus, attributes are identified by name plus (optionally) metadata ID. I will assume version >=0.17.0 in the rest of this answer.
Orion doesn't control violation of that rule when processing operations to create entities or append attribute on existing entities. In those cases, only one instance of the attributes with the same identification is taken an stored in the DB, the others are ignored. It is not recommended at all that a client do such kind of operations (in the future, Orion may check that condition and return an error to the client).
Taking account the above paragraph and regarding what happens when a convenience operation tries to get the value of one of the 2 attributes (AFAIK, the attribute type is not passed in the operation)? note that situation cannot happend. I mean, at Orion DB will never store two attributes with the same identification associated to the same entity.
Some additional comment regarding metadata ID: I don't recommend the use of metadata ID as any potential ID can be included in the name and you will get your client much simpler, e.g. you don't need and attribute with name=temperature and id=outside if you use name=temperature::outside or any other namespacing technique.
Background of question
Analysis of Zend_Log reveals following Class Diagram
Zend_Log:
uses ReflectionClass & Zend_Log_Exception
maintains reference to array of Zend_Log_Writer_Abstract
maintains references to array of Zend_Log_Filter_Interface
Zend_Log_Writer_Abstract
maintains reference to array of Zend_Log_Filter_Interface
maintains reference to Zend_Log_Formatter_Interface
Questions
Zend_Log_Filter_Interface relates with Zend_Log_Filter_Suppress, Zend_Log_Filter_Message & Zend_Log_Filter_Priority as depicted, is this correctly laid out in Class Diagram?
Is it okay to say that, the Zend_Log contains reference to array of Zend_Log_Filter_Interface and this is composition relationship (similarly for Zend_Log_Writer_Abstract)?
As it is obvious that Zend_Log_Filter_Interface is contained by both Zend_Log & Zend_Log_Writer_Abstract, while Zend_Log contains Zend_Log_Writer_Abstract, that makes Zend_Log_Filter referenced by both container (Zend_Log) and contained (Zend_Log_Writer_Abstract); is that some "Design Pattern", if yes what is the name?
Regards!
Zend_Log_Filter_Suppress, Zend_Log_Filter_Message, and Zend_Log_Filter_Priority all implement the Zend_Log_Filter_Interface interface. This is denoted using the empty arrow and dotted lines between them. The same is true for Zend_Log_Formatter_Interface and the three classes depicted below it.
Yes, that's correct. Whether to use an association (-->) or composition here could be debated since two Zend_Log instances could share a single Zend_Log_Writer_Db instance. As the writers and filters determine the overall behavior of the log, composition makes sense to me.
Each log instance can write to multiple writers. Messages are first filtered by the log itself, and any message that passes goes to every writer. Each writer filters the incoming messages as well. This allows you to ignore all messages below the WARN priority (at the log level) which get written to a file and further limit database logging to those at the FATAL level. You could accomplish the same effect by dropping the log-level filter array, but it would require duplicating the filtering in each writer.