It's is possible to do a insert on a mapplet without SQL transformation? Like in an expression?
Thanks
The short answer is ‘no’
A mapplet cannot contain a target, it CAN contain a source, which is kind of counter intuitive I suppose :)
You must always have at least one port going out of the mapplet, but as you suggest, it is possible to do ‘writing’ anyway, using a sql-trans.
Personally I prefer not to do so, and let all the writing happen immediately after the mapplet, since the sql trans is rather difficult to debug, and logging metadata in the repository is non-existing.
Related
I'm converting a Foxpro app and I'm having a bit of trouble with database table referencing/selection. I'm not in a position to run the Foxpro code as I only have code dumps with which to work. If someone could help me understand what is happening here I'd be most grateful. Yes... I searched.
SELECT tblMyTable
Set Filter To Inlist(cbid,123)
SELECT tblMyTable
Does the second Select simply reselect tblMyTable and clear the filter?
If not is a second instance being opened so you have one that’s filtered and one that isn’t?
If so how do I reference each instance since they have no names? Automatically 1 and 2?
Lastly if I’ve got it completely wrong just give me a small clue and I’m on it. Thank you!
I see that you are being misguided.
Second select has no special meaning. That line is not needed at all, but wouldn't do an harm either.
If it were a view, then 'refreshing' a view is done by using Requery(), not by doing another 1 or more selects.
In fact, 'set filter' is on the list of (almost all VFP developers') "never to use commands" , exceptions like this might happen unfortunately.
If you are doing a conversion by only using code dumps and no VFP environment at all, then your task should be extremely hard. I would instead prefer a rewrite from scratch. That would be faster even for seasoned VFP developers.
I have a quick question, what is the fast way to grab and delete an object from a mongo collection. Here is the code, I have currently:
$cursor = $coll->find()->sort(array('created' => 1))->limit(1);
$obj = $cursor->getNext();
$coll->remove(array('name' => $obj['name']));
as you can see above it grabs one document from the database and deletes it (so it isn't processed again). However fast this may be, I need it to perform faster. The challenge is that we have multiple processes doing this and processing what they have found BUT sometimes two or more of the processes grab the same document therefore making duplicates. Basically I need to make it so a document can only be grabbed once. So any ideas would be much appreciated.
Peter,
It's hard to say what the best solution is here without understanding all the context - but one approach which you could use is findAndModify. This will query for a single document and return it, and also apply an update to it.
You could use this to find a document to process and simultaneously modify a "status" field to mark it as being processed, so that other workers can recognize it as such and ignore it.
There is an example here that may be useful:
http://docs.mongodb.org/manual/reference/command/findAndModify/
Use the findAndRemove function as documented here:
http://api.mongodb.org/java/current/com/mongodb/DBCollection.html
The findAndRemove function retrieve and object from the mongo database and delete it in a single (atomic) operation.
findAndRemove(query, sort[, options], callback)
The query object is used to retrieve the object from the database (see collection.find())
The sort parameter is used to sort the results (in case many where found)
I make a new answer to remark the fact:
As commented by #peterscodeproblems in the accepted answer. The native way to this in mongodb right now is to use the
findAndModify(query=<document>, remove=True)
As pointed out by the documentation.
As it is native, and atomic, I expect this to be the faster way to do this.
I am new to mongodb and not entirely sure what your query is trying to do, but here is how I would do it
# suppose database is staging
# suppose collection is data
use staging
db.data.remove(<your_query_criteria>)
where is a map and can contain any search criteria you want
Not sure if this would help you.
When I'm using the Oracle updateXML()-Function, I have to address the path to the attribute which I'm trying to update (e.g. '/supplier/companyName/text()', 'Some Company Ltd').
OK, I'm fine with that. But what I actually doesn't understand is the text(). It seems that it is a function. Is that correct?
But what else is possible to use there?
Here's a pretty good explanation of the usage of text():
In the case of updateXML() I think it makes sense to use it because of what you want the resulting update to look like.
We have performance issue using for controls which gets number in the format of $dollars as input. In-order to over come this performance issue we used instead of and implemented the following calculate functionality in the bind of the control.
<xforms:bind id="Amount"
nodeset="instance('sample_form')/Amounts/Amount"
calculate="if (. !=0)
then format-number(xs:double(.),'$#,##0.000')
else ."/>
But the problem with the above code is, its converting the control's value into String type which leads to error in the controls which has its value dependent on this. Kindly provide me a solution for the above problem or provide a better recommendation to handle this situation.
If you only want to show the formatted value (which I assume to be the case since you are thinking of using a calculate), then you could put that expression you have on the calculate inside an:
<xforms:output value="..."/>
If you need both input and output, and you'd like the value stored in your instance to be just the unformatted number, then I don't think there is an easy way around using <fr:currency> other than somehow reimplementing the functionality provided by <fr:currency>. If you need both input and output, then I would recommend you to investigate this further to find, and then solve, the source of the performance issue.
I've been reading up on LINQ lately to start implementing it, and there's a particular thing as to how it generates UPDATE queries that bothers me.
Creating the entities code automatically using SQLMetal or the Object Relational Designer, apparently all fields for all tables will get attribute UpdateCheck.Always, which means that for every UPDATE and DELETE query, i'll get SQL statement like this:
UPDATE table SET a = 'a' WHERE a='x' AND b='x' ... AND z='x', ad infinitum
Now, call me a purist, but this seems EXTREMELY inefficient to me, and it feels like a bad idea anyway, even if it weren't inefficient. I know the fetch will be done by the clustered primary key, so that's not slow, but SQL still needs to check every field after that to make sure it matches.
Granted, in some very sensitive applications something like this can be useful, but for the typical web app (think Stack Overflow), it seems like UpdateCheck.WhenChanged would be a more appropriate default, and I'd personally prefer UpdateCheck.Never, since LINQ will only update the actual fields that changed, not all fields, and in most real cases, the second person editing something wins anyway.
It does mean that if two people manage to edit the same field of the same row in the small time between reading that row and firing the UPDATE, then the conflict that would be found won't be fired. But in reality that's a very rare case. The one thing we may want to guard against when two people change the same thing won't be caught by this, because they won't click Submit at the exact same time anyway, so there will be no conflict at the time the second DataContext reads and updates the record (unless the DataContext is left open and stored in Session when the page is shown, or some other seriously bad idea like that).
However, as rare as the case is, i'd really like to not be getting exceptions in my code every now and then if this happens.
So my first question is, am I wrong in believing this? (again, for "typical" web apps, not for banking applications)
Am I missing some reason why having UpdateCheck.Always as default is a sane idea?
My second question is, can I change this civilizedly? Is there a way to tell SQLMetal or the ORD which UpdateCheck attribute to set?
I'm trying to avoid the situation where I have to remember to run a tool I'll have to make that'll take some regexes and edit all the attributes in the file directly, because it's evident that at some point we'll run SQLMetal after an update to the DB, we won't run this tool, and all our code will break in very subtle ways that we probably won't find while testing in dev.
Any suggestions?
War stories are more than welcome, i'd love to learn from other people's experiences on this.
Thank you very much!
Well, to answer the first question - I agree with you. I'm not a big fan of this "built in" optimistic concurrency, especially if you have timestamp columns or any fields which are not guaranteed to be the same after an update occurs.
To address the second question - I don't know of any way to override SqlMetal's default approach (UpdateCheck = Always), we ended up writing a tool which sets UpdateCheck = Never for appropriate columns. We're using a batch file to call SqlMetal and afterwards running the tool).
Oh, while I think of it - it was also a treat to find that SqlMetal also models relationships to set a foreign key to null instead of "Delete On Null" (for join tables in particular). We had to use the same post-generation tool to set these appropriately too.