This is a follow-up to my question Dynamic table data visible in query editor but blank in data view.
While using Expression.Evaluate(document, environment) I was setting environment
either to #sections[Section1]
AddedTables = Table.AddColumn(Source, "Data", each Expression.Evaluate("shop_" & Text.From([shop]), #sections[Section1]))
or to #shared
AddedTables = Table.AddColumn(Source, "Data", each Expression.Evaluate("shop_" & Text.From([shop]), #shared))
but a working solution seems to be to explicitly define the inner and outer context objects in environment
AddedTables = Table.AddColumn(Source, "Data", each Expression.Evaluate("shop_" & Text.From([shop]), [shop_thehouse=shop_thehouse, shop_goldforex=shop_goldforex, shop_goldline=shop_goldline]))
So, my follow-up question here is 2-fold
Why does using #shared in the environment parameter not work?
After all, #shared contains all objects, so also the ones that were explicitly defined by the working solution (shop_thehouse,shop_goldforex,shop_goldline).
Is there another or better way to dynamically reference an existing table/query, instead of using Expression.Evaluate() ?
I believe your answer might be explained here.
As I understand it, #section returns information from a global perspective, whereas #shared returns it from a local perspective. I think, maybe, in your usage context, there is nothing for the shop names to find locally (using #shared) since what you're looking for is in other tables. I think that yours is a global use case since you're looking for shop information from another table. Hopefully someone more familiar than I can confirm this.
Related
I'm writing a C function/extension. It's a function that'll be called by a trigger. In it, when a trigger is fired, I need determine the name of the current database.
It's a requirement that using SPI_prepare(), SPI_exec() isn't allowed in this case, therefore querying current_database() won't work.
Some other SPI_get* will be ok. Or, accessing to the current database name via TupleDesc or TriggerData somehow too.
How to do it?
It's not clear to me which of postgresql's server-internal programming interfaces are usable in SPI extensions. However, the implementation of the current_database SQL function does this:
Name db;
db = (Name) palloc(NAMEDATALEN);
namestrcpy(db, get_database_name(MyDatabaseId));
PG_RETURN_NAME(db);
So, I think get_database_name(MyDatabaseId) is the incantation you want. It returns a C string, which your C extension can use directly -- the rest of the above is to box up the string in a Datum object so the query evaluator can work with it.
I figured out that a function called "current_database()" seems useful which seems similar to "select database()". Later returns a string which represents the name of the database.
Yes, a parameter that your extension will get in order to deduce context or so.
PL/SQL can create functions. These can in turn call C-Language extensions via shared libraries. Finally, the name can be delegated from database towards extension.
Consider the following scenario:
Our Django database objects must rely on IDs that are provided by external service A (ESA) - this is because we use this ID to pull the information about objects that aren't created yet from the external directly. ESA might shut down soon, so we also pull information about the same objects from external service B (ESB), and save them as a fallback.
Because these IDs are relied on heavily in views and URLs, the ideal scenario would be to use a #property:
#property
dynamic_id = ESA_id
And then, if ESA shuts down, we can switch easily by changing dynamic_id to ESB_id. The problem with this though, is that properties cannot be used in queryset filters and various other scenarios, which is also a must in this case.
My current thought is to just save ESA_id, ESB_id, and dynamic_ID as regular fields separately and assign dynamic_ID = ESA_id, and then, in case ESA shuts down, simply go over the objects and do dynamic_ID = ESB_id.
But I feel there must be a better way?
Having ESA_id and ESB_id fields in the same table is a good solution, then you have some kind of setting (DEFAULT_SERVICE_ID='ESA_id'|'ESB_id') and your code change the lookup based on this option.
Here you can see an aproach to create filters dynamicly
https://stackoverflow.com/a/310785/1448667
I need to create an like/dislike system which can be used on any entity. I'm going to create a Like entity with an 'Id', 'Entity' (can be anything), 'author' (ManyToOne with User class) and 'like' (boolean).
I just want to know if there is a good way to do it ?
I can't use the table inheritance (mappedsuperclass) because this entity will be part of a bundle (SocialBundle) which can be used on several project (It will be a vendor).
I have no code to show you because i'm still in the analysis part.
Thanks !
Create an interface for that entity and later you can map this interface to any entity using addResolveTargetEntity method. See this.
I'm working on an events site and have a one to many relationship between a production and its performances, when I have a performance object if I need its production id at the moment I have to do
$productionId = $performance->getProduction()->getId();
In cases when I literally just need the production id it seems like a waste to send off another database query to get a value that's already in the object somewhere.
Is there a way round this?
Edit 2013.02.17:
What I wrote below is no longer true. You don't have to do anything in the scenario outlined in the question, because Doctrine is clever enough to load the id fields into related entities, so the proxy objects will already contain the id, and it will not issue another call to the database.
Outdated answer below:
It is possible, but it is unadvised.
The reason behind that, is Doctrine tries to truly adhere to the principle that your entities should form an object graph, where the foreign keys have no place, because they are just "artifacts", that come from the way relational databases work.
You should rewrite the association to be
eager loaded, if you always need the related entity
write a DQL query (preferably on a Repository) to fetch-join the related entity
let it lazy-load the related entity by calling a getter on it
If you are not convinced, and really want to avoid all of the above, there are two ways (that I know of), to get the id of a related object, without triggering a load, and without resorting to tricks like reflection and serialization:
If you already have the object in hand, you can retrieve the inner UnitOfWork object that Doctrine uses internally, and use it's getEntityIdentifier() method, passing it the unloaded entity (the proxy object). It will return you the id, without triggering the lazy-load.
Assuming you have many-to-one relation, with multiple articles belonging to a category:
$articleId = 1;
$article = $em->find('Article', $articleId);
$categoryId = $em->getUnitOfWork()->getEntityIdentifier($article->getCategory());
Coming 2.2, you will be able to use the IDENTITY DQL function, to select just a foreign key, like this:
SELECT IDENTITY(u.Group) AS group_id FROM User u WHERE u.id = ?0
It is already committed to the development versions.
Still, you should really try to stick to one of the "correct" methods.
I'm building a CiviCRM extension, which would also have an admin section with UI for setting various configuration specific to the extension. I'm looking for a recommended approach for storing the configuration in the database.
One way is to create a new table in the database specifically for this purpose, but this seems like an overkill if there are only a couple of options to be saved.
Another way could be to use the civicrm_setting table, which kind of makes sense at first, but I'm not sure if this table is meant to be used for this purpose.
Any advice would be appreciated.
Yes, you can and should definitively use civicrm_setting.
civicrm_setting has a column group_name that should contain a unique identifier for your extension. I usually put the full name of the extension, like org.example.extension but it could be any string, and in core they use label name (e.g., Preference settings).
To interact with those settings, you can do the following :
// save the setting
CRM_Core_BAO_Setting::setItem($value, 'My group name', 'my_setting_name');
// get the setting
$setting = CRM_Core_BAO_Setting::getItem('My group name', 'my_setting_name');
// get all the setting for you extension
$settings = CRM_Core_BAO_Setting::getItem('My group name');
There seems to be an API for Setting but it doesn't seem to work well in CiviCRM 4.4.x. Don't know if it is better in CiviCRM 4.5.
What you could also do (our current practice) is store your configuration logic in a special class using the singleton pattern (as CiviCRM does itslef). If you want to see an example check this:
https://github.com/CiviCooP/no.maf.oppgavexml/blob/master/CRM/Oppgavexml/Config.php